2009年10月21日

Blogger の「続きを読む」機能

ここ2〜3ヶ月くらいで、Blogger にクラウドタグと「続きを読む」機能が追加された。

すばらしい!

あとは、関連記事のリスト表示の対応が入れば、全部 Blogger 内でまかなえるのかなぁ。。。

ただし、ちょっとだけ問題がでた。

今使っている投稿アプリ ecto では 投稿後に再度 Blogger からデータを再取得してその内容を保存するような動作をしている。

このとき、Blogger から流れてくるデータでは 「<!-- more -->」が「<a name='more'></a>」に置換されてしまっている。

そのままで jump break と同等に機能すれば良いのだが、どうもそうでは無いらしい。

再度修正したいときは、都度確認し修正が必要のようである。

ecto の使い方がわるいんかなぁ。。。


[全文を読む]

2009年10月19日

VIA EPIA EN の設定のまとめ 2009Q4

気がついてみると VIA EPIA EN12000 と Linux の Tips がたまったので、まとめてみた。

PadLock

  1. Debian で VIA の PadLock を使ってみる
  2. IPSec のスループット
  3. Linux でボリュームを暗号化する (1) - swapの保護
  4. Linux でボリュームを暗号化する (2) - LVMの保護
  5. Linux でボリュームを暗号化する (3) - 性能比較

Watch Dog Timer

  1. VIA EPIA-EN で watchdog を設定

Onboard NIC / VT6122

  1. VT6122 の性能(1) - Linux のドライバの準備
  2. VT6122 の性能(2) - VIA Velocity の出自
  3. VT6122 の性能(3) - ネットワークスループット測定
  4. VT6122 の性能(4) - ドライバの強化
VIA EPIA EN のその後 (追記2009/12/09)

性能を使い切るポイントはある程度掴めたので、再度ファイルサーバとして組み直して使う事にした。 高負荷状態になってもたいして速くない電力を食わないので好都合かなぁ。 なので、これ以上このボードに特化したTipsはおしまい。

あれ、、、なぜかGbE-PCI2GbE-PCIe3が手元にあるのは何故なんだろう。。。


[全文を読む]

2009年10月15日

IPSec のスループット

ネットワークのスループットを測定する環境を整えたので、次いでに IPSec を通してた時のものも測定してみた。

測定の条件は

  1. スループット測定ツール nuttcp の計測用データチャンネル 5001/tcp を上り/下りにそれぞれ IPSec に通す。
  2. racoon ver.1 でサポートされていない暗号化スイートも測定したいので、鍵を手動で設定する。
  3. ESP認証/暗号の組み合わせで計測する。(AHは使わん)
  4. 追加で IPComp での圧縮の効果を見たい気がする。
複数の認証/暗号の組み合わせで測定する為にスクリプト(measure_ipsec_throughput.sh)化した。

setkey で、手動で鍵を設定する方法は多々情報(12)があるので、そちらを参考にして欲しい。ただ、IPComp を組み合わせる例が乏しいのでこの部分だけ。

IPComp を組み合わせて使う

IPSec設定済みで、ESPのみを使うSPDが次にようになってるだろう。

...
spdadd xx.xx.xx.xx[port] yy.yy.yy.yy tcp -P out ipsec esp/transport//require;
...

このときSPDのルールの順番が重要になる。カプセル化の下の方から、要は IPComp ⇒ ESP ⇒ AH の順に書き下していくことになる。

従ってIPCompを組み合わせるには、次のようにすればよい。

...
add xx.xx.xx.xx[port] yy.yy.yy.yy ipcomp zzzz -C deflate;
spdadd xx.xx.xx.xx[port] yy.yy.yy.yy tcp
	-P out ipsec ipcomp/transport//use esp/transport//require;

ただ、ベンチマークに流れるデータは「0」の羅列なので、いまいち効果が分からん。。。

なので計測は諦めた。

IPSec スループットの計測

前とほぼ同じ環境とmacbook pro を加えたものを用意、全ての計測に MTU 1500 / ロック周波数変更は全て無効にしMAXにした。また、TCP/IP通信に関するパラメータを修正せずにデフォルトにした。

  • ref1 - M2NPV-VM / Athlon64X2 2.0GHz / DDR2-667 4GB / Intel Pro/1000PT (外付け)
  • ref2 - M4A78-EM / Athlon X2 5050e 2.6GHz / DDR2-800 8GB / RTL8112
  • via - VIA-EN12000EG / VIA C7 1.2GHz / DDR2-533 1G / VT6122
  • osx - MacBookPro5,1 / Intel Core 2 Duo 2.4 GHz / DDR3-1066 2G x 2 / onboard Gigabit Ethernet
  • hub - Gigabit Hub(GS908M)
認証/暗号 ref1⇔ref2 ref1⇔via ref1⇔osx
throughput
(Mbps)
CPU % throughput
(Mbps)
CPU % throughput
(Mbps)
CPU %
ref1ref2 ref1via ref1osx
no ipsec 941.35801028 785.1857650 936.9429954
941.24611724 723.71001299 938.34511877
null/null 934.68349938 566.89471393 932.07073162
787.44951846 520.28801399 879.31272599
null/des-cbc 229.5461998 72.9094295 136.6533314
197.07681426 73.4657499 129.1215699
null/3des-cbc 110.51731004 30.8918287 59.206417
76.8033111 30.5976199 56.5818398
null/aes-cbc 466.79899933 392.07391491 475.77899543
472.17962836 396.22641799 376.38902299
null/aes-ctr 495.41637758 218.6071771
383.9987167 258.74301799
null/blowfish-cbc 316.03279911 77.6054374 263.77951531
244.9774114 84.1580499 228.48101399
null/twofish-cbc 372.53179919 100.8360573
289.2720159 102.0088599
null/camellia-cbc 340.991610015 86.7841360
267.3560185 84.5675499
hmac-md5/null 537.28579924 244.7170787 578.86759949
453.24482914 230.20191199 572.58092999
hmac-sha1/null 370.086110015 360.37542086 414.47069941
296.1913117 350.02872099 469.55875798
hmac-sha256/null 307.00789916 302.931510041 278.90011733
240.0495124 336.25121996 248.91492899
aes-xcbc-mac/null 447.60179920 216.0013680
347.98811312 271.08012199
hmac-md5/3des-cbc 101.51721005 29.0609188 57.006917
71.0862111 28.45191100 54.5636498
hmac-md5/aes-cbc 326.01559917 205.8441979 349.03388027
266.2639185 198.65111299 296.44312798
hmac-sha1/3des-cbc 94.18991005 30.1900185 56.661915
66.1646121 29.8474299 52.0154496
hmac-sha1/aes-cbc 259.36149915 253.11579956 275.36619825
202.5055124 286.00772093 270.10912697
hmac-sha1/aes-ctr 257.31529914 193.6954497
199.9059123 209.87451699
aes-xcbc-mac/aes-cbc 283.08649915 207.26131162
225.1556134 233.39072699
aes-xcbc-mac/aes-ctr 281.39699915 154.4989770
220.3145124 178.53991399

異様にたくさん計測したが、あんまり意味が無い気がしないでもない。

  • 暗号化方式の性能は
    aes系 > blowfish/twofish/camellia >> DES > 3DES
    VIA C7 では aes系 >> それ以外
  • 認証方式の性能は
    hmac-md5 > aes-xcbc-mac > hmac-sha1/hmac-sha256
    ただ、あまり差異はない。
    VIA C7 では hmac-sha1/hmac-sha256 >> それ以外
  • des-cbc/3des-cbc は他の暗号化方法に比べて5~10倍くらい遅い。もう、見る影が無い。
  • aes 系の実装には多くの開発リソースが割かれており、x86 コードでも十分早い。VIA PadLock が圧倒的に有利という訳ではない、不利という訳でもない。
  • 個々のNICドライバの個性がある。
    e1000e(Linux) / nvenet(MacOSX) に関しては送信時のCPU負荷が100%になる傾向があり、r8169 に関してはどう考えてもCPU利用率が低くなる。
    これが NIC 自体の性能か、TCPと組み合わせで何らかのビジーウェイトが起きるのかは、いまいち不明。。。nuttcp/netperf で発生するトラフィックパータンに対する適性なのだろうか。
    送信性能が上がるチューニングが必要なのだろうか?
  • 普通運用する hmac-sha1/aes-cbc は 約250Mbps のスループットが出る。PadLock を使えば同様の性能が出る。

結論

VIA-EN12000EG 上の Linux で IPSec を使うと約250Mbps程度のスループットの性能があり、Athlon64X2 2.0GHz と同程度の性能である。

Intel Atom はどの程度なのだろうかぁ?


[全文を読む]

2009年10月6日

VT6122 の性能(4) - ドライバの強化

元々 via-velocity は、少し古いバージョンの velocityget ソースを整理したものだった。ただ、現在の双方のバージョンを比べると、via-velocity に含まれていない要素がある。

  • EnableMRDPL (Memory-Read-Multiple)オプション
  • VIA 的には「Adaptive Interrupt」と呼ばれるもの
    (txque_timer/rxque_timer/tx_intsup/rx_intsupオプションとその関連部分)

これは、分岐後にVIAによって追加されたものか、意図的に省かれたのもか、どちらなのかは正直分からない。

EnableMRDPL (Memory-Read-Multiple)オプション

最初の要素は、PCIのバースト転送のモードをなんか指定するものらしいが、ベンチマーク上は効果がなかった。 PCIに詳しくなければいまいち内容が分からないし、デフォルトが無効なので、今回は見送った。

VIA 的には「Adaptive Interrupt」と呼ばれるもの

「適応割り込み」と称しているが、単に割り込みを一定数間引いたり、一定時間遅延を入れるだけのようで、 特に割り込みの頻度に応じて動的に変更はしない。。。なんかなぁ

うんで、機能追加パッチを作ってみた。(velocitygetの処理を流用)

  1. via-velocity の adaptive interrupt 関連の機能追加パッチ (debian lenny/kernel-2.6.26用) / via-velocity-adaptive-intr.patch

前出の修正パッチの後に当てればいい

# mkdir via-velocity
# cp Makefile-via-velocity-only via-velocity/Makefile
# cp /usr/src/linux-source-2.6.26/drivers/net/via-velocity.[ch] via-velocity/
# patch -p 3 -d via-velocity < via-velocity-fixed-wol.patch
# patch -p 3 -d via-velocity < via-velocity-fixed-int_works.patch
# patch -p 3 -d via-velocity < via-velocity-adaptive-intr.patch
# cd via-velocity
# make install

スループット性能の比較

前回と同じ環境で、velocityget と via-velocityの「Adaptive Interrupt」パッチ有/無の3種類の場合を測定した。

velocitygetvia-velocity
パッチ無し
via-velocity
パッチあり
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1targetref1
target ⇒ ref1 655.484199 %11 % 646.403699 %12 % 724.780999 %12 %
target ⇐ ref1 741.275566 %4 % 709.246580 %2 % 762.342051 %5 %
mtu 1500 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

velocitygetvia-velocity
パッチ無し
via-velocity
パッチあり
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1targetref1
target ⇒ ref1 816.054432 %7 % 816.154130 %7 % 814.900731 %7 %
target ⇐ ref1 989.874548 %9 % 944.481346 %8 % 989.832346 %9 %
mtu 9000 / DMA_length=6 / それ以外のモジュールパラメータはデフォルト値

考察

mtu 1500 のとき、送信性能が10%程度上がった。受信性能はほぼ velocityget と同程度になったが、CPU負荷率は低くなった。mtu 9000 のときは、velocityget と同程度になった。

受信時のCPU負荷率低下は面白い。NAPI化すればより軽くなるのかなぁ。e100?系の適応なんとかの動的アルゴリズムを流用すればもっと良くなるのかなぁ。もっと送信性能を上げるにはどうすれば良いのだろう。。。

スループットのベンチマーク上の結果だけなので、レイテンシとかはどうなんだろう。。。

本来 ethtool へのインタフェース経由で設定するものを、モジュールパラメータに載せて、固定値になっているのも気になると言えば気になる。

ちまちまパッチを切るのは面倒だから、どっかにレポジトリ借りて、最新版のバニラソースに作業するのがいいのかなぁ。

ふぅむ。

近年、VIA の NIC のシェアはかなり落ちている。大抵の onboard NIC は RealTek の奴だったりする。また、Windows 64bit系の4G問題とかも敬遠される原因になっている。

廃れつつ、傾きつつ、そんなものの為に作業する奴がいないんだろうなぁ。

VIA EPIA は本当に不憫な奴だ。




今年分の作業は、この辺かなぁ、、、では


[全文を読む]