GPL PV Drivers のパフォーマンス

製品の仮想化技術には、 VMware でも Parallels でも、 Windows をゲストとして動作させる時に I/O パフォーマンスを向上させるためのドライバが用意されています。

このような仮想化デバイスのドライバを使用しない場合、仮想マシン上で動作する Windows などの OS は、仮想マシン技術がエミュレートする PCI バス上のディスクコントローラに対して I/O を行います。これに対して、先のドライバは VMware などの仮想化ソフトウェアと直接 I/O データをやりとりするため、パフォーマンスが向上する仕組みになっています。

さて、 Xen においてもこのようなドライバの仕組みは Paravirtual Driver (準仮想化ドライバ) という形で存在しています。 Xen のソースコードをダウンロードすると unmodified_driver/ などというディレクトリがあったりしますが、それがまさにそのドライバです。

アンオフィシャルですが、 Windows 用のオープンソースな PV ドライバも存在しています。

• http://wiki.xensource.com/xenwiki/XenWindowsGplPv


• http://www.meadowcourt.org/downloads/

しかし、ただ単純にベンチマークをとってみると...



【検証環境】

・HP ProLiant ML115 G1
・Athlon64 X2 5600+ (2.8GHz x2)
・8GB PC5300 RAM
・Hitachi HTS72323 320GB 2.5inch HDD
・openSUSE 11.1 + Xen 3.3
・Windows xp SP3 (x86)


あれれ～？ PV ドライバを入れた場合のほうがパフォーマンス伸び悩んでますね。というか QEMU のハードウェアエミュレーションと比較し完敗です。何かの間違いでしょう。しかし、再計測しても再計測してもこの結果がひっくり返ることはありませんでした。

そこで、このツールで計測をはじめてから計測が終わるまでの時間を、愛用の G-SHOCK で測ってみました。なお Crystal Disk Mark のソースコードを確認したところ決まった量の I/O 負荷をかけて、それの所要時間から性能を算出しているようです。つまり計測値はアテにならなくても、 I/O に要した"時間"は信用できると考えられます。結果は以下のとおりでした。

PV ドライバ使用時： 3分23秒
PV ドライバ未使用時： 3分31秒

なんだ、やっぱり PV ドライバのほうが早かったんですね。約 6 % の性能アップしていたようです。しかし、これでは本当のスループットがわかりませんね。敢えていえば QEMU エミュレーションから 6% しか性能向上がない PV ドライバというのも随分寂しいものです。（ XenSource や Novell が作っているドライバはもっと高いパフォーマンスを示してくれることでしょう）

PV ドライバには I/O パフォーマンスを向上させる以外のメリットとして CPU に対する負荷の低減があります。無意味に低レベルなハードウェアの真似（ゲストによる I/O ポートへのアクセスをトラップしエミュレーション）をする必要がなくなるからです。

I/O パフォーマンスについてはまた計測方法を検討して検証をしてみたいと思います。というわけで、今日はおやすみなさい。

"家庭内乱"管理を少しでもラクにするには

このサイトをご覧いただいている方には、自宅のネットワークを仕切っている方、また実家や親戚の家のネットワーク（家庭内乱）管理をついつい頼まれてしまい、なかなか断れずに面倒をみるハメになっている方なんて、そこそこ多いのではないでしょうか？少なくとも私は実家や親戚宅のネットワーク管理にたびたびかり出されています。

また、ネットに繋がるようにして帰ってくるのは簡単ですが、いざしばらくすると「ネットに繋がらなくなった」と電話がかかってきたり、いろいろな都合でネットワークの変更が必要になるケースがあり、とっても面倒なものです。私は、そういう時のために、（内容はケースバイケースですが）簡単な設定資料を作っていたりします。


このネットワークにおいて、以前機器の移設時に配線ミスによる混乱があったため、この資料は、どちらかといえば物理配線にフォーカスした内容となっています。とはいえクライアント側の設定に必要な項目は網羅されているので、この資料があれば

• 問い合わせを受けたときに何がどうなっているかを思い出せる
• ユーザ自身で有る程度の配線見直しなどが可能
• クライアントの設定方法を書いておけばユーザが自分たちで新ノードを追加できる。もしくは設定業者が対応できる
• 大きなトラブルがおきたとしても、他の人に対応を引き継げる・・・ことがある

などのメリットが生まれます。

ところで、今回紹介した図は2006年1月時点の私の実家のネットワーク構成に基づいたものです。私は実家から東名高速道路で約300km離れた地点に住んでいるため、なかなか度々面倒を見に行くことはできません。その後実家のネットワークはADSLからひかり電話にサービスを変更するためファイバの引き込みONUなどを設置したのですが、その作業の担当者にこの資料を見せることで、スムーズにWAN側の切り替えを済ませることができたそうです。

パスワードなどの機密情報も含めて記載されている点など、賛否両論はあるでしょうが（そもそもセキュリティ要求が高いような場所ではWANの切り替え工事を電話工事の担当者にやらせないと思いますが:-）、この手の資料は、「備えあれば憂いなし」です。


なお、構成が変わったときにはドキュメントの更新もお忘れなく。

404のかわりに任意のレスポンスコードおよびエラーメッセージを返すには

mhag が、存在しない URL にアクセスされたときに 404 ではなく別のレスポンスコードを返そうと頑張っていました。詳しくはこちら。

最初は目的のレスポンスコードを返す CGI スクリプトを書いて、 mod_rewrite で URL を書き換えて実現していましたが、この方法では 404 のたびに CGI スクリプトが起動されるため効率面ではあまり思わしくありません。

ErrorDocument でレスポンスコードおよびエラー時のドキュメントファイルを指定することもできますが、他の方法として、（静的でよければ） mod_asis を使うと、レスポンスコードもエラーメッセージも自由に設定できます。

これらの方法であればプロセスが毎回 fork したりせずにすむので、アクセスが多い Web サイトでも安心ですね。

その他の解としては mod_perl などで任意のレスポンスを返すハンドラを書いてしまう手もあるでしょう。この方法ならヒット毎の fork を防ぎつつ、動的にレスポンスコードやメッセージを自由に制御できます。

iTunesにID3v2タグを破壊される

去年の春から本格的に Mac ユーザとなった私ですが、新型 MacBook への乗り換えにともない MP3 も新しいマシンに移しました。

もともと Windows の iTunes で管理していたファイルを MacBook に移した段階で ID3 タグが一部化けたりしていて、ちょっとだけ困っていたのですが、 MacBook から新型 MacBook にファイルを移して iTunes に再度インポートしたところ、これまで大丈夫だったファイルまで多数文字化けしてしまいました。

面倒だったのでこれまで放置していたのですが、忙しい中の現実逃避がてら復旧作業にやっととりかかった、、、のですが、、、、

Perl モジュールの MP3::Tag をインストールしていじりはじめたところ、思ったよりも状況は深刻なことがわかりました。当初の想定では Windows 時代に作成した MP3 の ID3 タグが UTF-16LE ベースで記録していないのでバケているのだろう、だからインポート前に UTF-16LE にエンコードをかえてやればいいと思っていたのですが... 実際には、iTunes がバケた ID3 タグをファイルに rewrite してしまっていて、文字化けがどういう経緯でどうなったのか判断が不能な状態になっていました....

まあ手作業でタグをつけ直せる範囲なので(ライブラリ全体で3500曲ぐらい)、気がむいたときに気になるところから直していくことにします。なお、だいたい影響を受けているデータは2001年〜2003年頃にリッピングし、ちまちま手でタグをうっていた頃のファイルなどがメインでした。 MacBook 上の iTunes でリッピングしたファイルもいくらかおかしくなっていましたが.....

しかし、勝手に ID3 タグ書き換えられるのは正直困りますね。いや、最近はそんなことされても（心の奥底で否定しつつ）文句言わずに使ってあげるアポー信者として堕落した日々を過ごしているわけですが:)

時代は 802.11n なので...

先日、無線LANのアクセスポイントのファームウェアをアップデートしたわけですが、それ以後、実は新しい問題が発生してしまいました。

なぜか新 MacBook がレジューム復旧後にアクセスポイントに再接続できないのです。

アクセスポイント側を再起動すると解決することから、アクセスポイント側のソフトウェア的な問題だと思われます。とはいえ 2003 年頃の製品だけにアップデートもう期待できないので、あきらめて新しいものに交換することにしました。

悩んだ末、最終的に Aterm WR4500N を選定。 8,000 円をきる価格で入手できる 802.11n & b/g 対応アクセスポイントです。最初は WR8500N も検討したのですが

• ギガビットイーサポート ... でもそんなにたいしたスループットが期待できないからよくね？（クライアント的に）


• IEEE802.11a対応 ... X31 の頃は g 対応の無線モジュールが乗ってなかったから a つかってたけど、今は a 付き端末はあんまり使わないから、もう g でよくね?


• 300Mbps 対応 ... でも MacBook どうやら 150Mbps モジュールらしいよ?

などなど、ここでがんばって倍近い投資をしたところでなんのご利益も得られず、そもそもアクセスポイントも昔は2万以上出して買ってたわけですが、今時はアクセスポイントという製品群自体がずいぶん安くなったし、本当に高いスペックの製品がほしくなったらその時のハイスペック機に買い直せばいいやという結論にいたり WR4500N に落ち着きました。

今ってルータモードのほかにアクセスポイントモードってのがあるんですね。そのほかにも、最近の AP は設定項目などもすっきりしたように思います。6年ぶりに無線LAN親機の設定をして感動しました。

時代は 802.11n だけど....

ご無沙汰してます。ファームウェアアップデートには無頓着なブログ主であります。

新型 MacBook を購入しウハウハなワタクシですが、 MacBook-MacBook 間で大きなデータの転送をかけると、無線LANルータの WR7600H が死ぬので、久々にファームウェアのアップデートをかけてみました。

この無線LANルータはもともと 2003 年の ThinkPad X31 リリース直後に IEEE802.11a の無線LAN環境を構築するために購入したものです（当時、私の実家にはオレ専用の 802.11a と家族用の 802.11b の２つのAPがありました）。

アップデート前のファームウェアバージョンは 7.8 ぐらい。どうやら2003年上旬リリースのファームウェアのままこれまで動かしていたようです。一気に2006年リリースの最終版ファームウェアと思われる 8.6b へアップグレード。データ転送中にAPが死ぬことはなくなりました。

しかし今時のマシンだと IEEE802.11n とかいうヨクワカラナイ規格で、理論値150Mbpsとか電波到達距離200mとか意味がわからないスペックになってますね。今時は無線LANメインの生活だし、そろそろAP買い換えてもいいかな〜。