Google Code Prettify

ラベル VIA EPIA の投稿を表示しています。 すべての投稿を表示
ラベル VIA EPIA の投稿を表示しています。 すべての投稿を表示

2009年12月9日

VIA EPIA EN のその後

VIA EPIA EN12000 を24時間運転してサーバ運用してる。 以前は、時々ハングアップしていたのため、保険で watchdog 設定をしていたのだが、 奇妙なことに安定動作している。

# uptime 
 16:32:08 up 48 days, 21:24,  1 user,  load average: 0.06, 0.07, 0.01

取り敢えず、1ヶ月半くらい連続運転している。

はて?
なにが効果あったのかな?

環境としては、

  • VIA-EN12000EG / VIA C7 1.2GHz
  • DDR2-533 1G (IO-DATA DX533-1G)
  • PATA SSD 32G (TS32GSSD25-M)
  • SATA HDD 1Tx2 (WDC WD10EADS-00L/WDC WD10EADS-00M)
  • Debian lenny の標準的なパッケージをほぼ使ってる。
TimeMachine の バックアップ先になっており、一時間ぐらいの間隔で バースト的に Network I/O や Disk I/O が同時に発生する状況にある。

取り敢えずは、今のところ安定している。。。

まぁ、ネットワーク負荷を計測するときには、 負荷をかけるとハングアップすることが多々あった。 追っかけてみようかと思って保留して、 計測後の環境ではハングアップが全く無くなったので放置してしまった。

計測前と計測後には大きく2点の作業をしてある。

メモリのフリーページの調節

運良くコンソールにメッセージが出てきたとき「lockup」とかは見た記憶がある。 別のメッセージだったかもしれない。 色々調べて、「メモリーのフリーページの不足ぎみが NICドライバ内でのlockupを引き起こす」とか適当に結論づけて、 次の設定をした気がする

# echo "vm.min_free_kbytes = 8192" >> /etc/sysctl.conf

ただ、もっと良い設定があって次のようなスクリプトを自前のバックアップ処理の後に入れている

## pagecache clear & dirty page & inode cache clear
/sbin/sysctl -w vm.drop_caches=3
#
/sbin/sysctl -w vm.drop_caches=0

この設定は、結構気分の問題な気がする。

NIC ドライバの変更

計測中も、ベンダ提供のものか、自前で修正したものを使っている。 計測後は、自前で修正したものを使って長期運用している。。。ってその為に改良したしなぁ。

Debian 標準カーネルに含まれているvia-velocityドライバはバースト的なI/Oにはlockupするような、気がする。

まとめ

人生で初めて家の電灯の安定器のコンデンサが破裂していく音を聞いた。

「しゅるしゅるしゅる〜〜、ぷぅん」って。

VIA-EN12000EG のコンデンサが減ったった時が、VIA とのお別れですね

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 は本当に不憫な奴だ。




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

2009年9月30日

VT6122 の性能(3) - ネットワークスループット測定

スループットを計測するツールは何種類かある。

  • ttcp / nttcp / nuttcp
    ttcp が古のツールでソースは色んなバージョン(1,2)が散見される、SGI の人が改良したのが nttcp (元サイトは http://www.leo.org/~elmar/nttcp/ だったらしいが、既に無くなっている)。nuttcp は、nttcp をベースに改良が続けられたもの。使うならば nuttcp かなぁ。
  • iperf
    Java ベースの GUI 付きがあるので、ベンリかも
  • netperf
    スループット以外にもテスト項目の種類が豊富。ただし、man ページが不完全でなので付属の HTML/PDF を参照する必要がある。
  • SmartBits
    商用でよく使われている奴ですね。

まぁ、スループットの測定ならば iperf を使えば良いが、CPU の負荷状況を見たいので nuttcp を使ってみた。

VIA-EN を含めて以下の3台とHUBを用意し、3台ともhubに直結した。

  • target - VIA-EN12000EG / VIA C7 1.2GHz / DDR2-533 1G / VT6122
  • ref1 - M2NPV-VM / Athlon64X2 2.0GHz / DDR2-667 4GB / Intel Pro/1000PT (外付け)
  • ref2 - M4A78-EM / Athlon X2 5050e 2.6GHz / DDR2-800 8GB / RTL8112
  • hub - Gigabit Hub(GS908M)
また、測定自体は、clock skew を避けるため全て ref1 上で計測した。cpufreq によるクロック周波数変更は全て無効にしMAXにした。 ref2 に関しては ref1 自体の評価にのみ使った。

ref1 ⇔ ref2 間

ref1 / ref2 ともに mtu 1500 に設定して測定した。

# ssh -f ref2 -- "nuttcp -S -1"
# nuttcp -t ref2
 1123.8690 MB /  10.01 sec =  941.3733 Mbps 11 %TX 27 %RX
# ssh -f ref2 -- "nuttcp -S -1"
# nuttcp -r ref2
 1122.3750 MB /  10.00 sec =  941.0966 Mbps 33 %TX 16 %RX
これを表にすると、
スループット
(Mbps)
CPU 利用率
ref1ref2
ref1 ⇒ ref2941.373311 %27 %
ref1 ⇐ ref2941.096616 %33 %
mtu 1500

まぁ、順当に ref1 は送受信ともに約 940Mbps 程度の性能を持っている事が分かる。

target ⇔ ref1 間

target の ドライバ via-velocity/velocityget のそれぞれに対して、mtu 1500 かつモジュールパラメータを設定せずに(ドライバのデフォルト値で)計測した。

velocitygetvia-velocity
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1
target ⇒ ref1 655.217499 %12 % 340.168127 %9 %
target ⇐ ref1 738.798768 %3 % 514.590042 %2 %
mtu 1500 / モジュールパラメータは全てデフォルト値

熟考

結果を見れば、明らかに velocityget の方が性能が高いように思われるが、ソースを見比べるとモジュールパラメータ DMA_length のデフォルト値が、それぞれのドライバで異なる (velocitygetは6/via-velocityは0)。

DMA_length は、チップ内のバッファとメインメモリの間を転送する DMA の処理サイズを指定するらしく、大きなサイズであれば PCI バスの使用効率が上がるので、スループットに影響しそうである。

なので、DMA_length を 0〜7 に振って再度計測し直してみた。

DMA_lengthvelocitygetvia-velocity
(via-velocity
/velocityget)
スループット
(Mbps)
CPU 利用率スループット
(Mbps)
CPU 利用率
targetref1targetref1
target ⇒ ref1 0 369.505328 %11 % 340.182727 %10 % 0.920643
1 398.938239 %11 % 414.574740 %7 % 1.039195
2 497.400464 %9 % 494.275760 %8 % 0.993717
3 539.035684 %9 % 540.716080 %10 % 1.003117
4 610.574399 %10 % 608.103199 %10 % 0.995952
5 646.153099 %11 % 640.971199 %10 % 0.991980
6 655.484199 %11 % 646.403699 %12 % 0.986146
7 652.173299 %12 % 647.739799 %10 % 0.993201
target ⇐ ref1 0 450.885036 %2 % 502.953242 %2 % 1.115480
1 490.215038 %2 % 580.651856 %2 % 1.184483
2 599.558448 %3 % 642.568463 %2 % 1.071736
3 661.059252 %3 % 685.175374 %3 % 1.036480
4 719.696564 %3 % 709.948283 %3 % 0.986454
5 731.320969 %5 % 710.111380 %3 % 0.970998
6 741.275566 %4 % 709.246580 %3 % 0.956792
7 738.297565 %3 % 710.145982 %3 % 0.961869
mtu 1500 / モジュールパラメータはDMA_length以外はデフォルト値

DMA_length の値を合わせれば、送受信のスループットに関しては velocityget/via-velocity にほとんと差異は無く、強いて言えば velocityget の方が受信に関して 4〜5% 高く、処理が軽い。送信に関しては双方同じ程度に CPU を使い切って頭打ちになっている。VIA C7 では 1Gbps は吐けないのかぁ。。。

まぁ、DMA_length は velocityget のデフォルト値の 6 が推奨値かなぁ。ちなみに、NetBSDでのドライバ vge だと 4 だった。

ただ、DMA_lengthの値でスループットの差異が出るのは VT6122などのPCIベースの場合だけで、PCIe ベースの VT6130 ではどの値でも違いが無かった。。。多分省かれてしまったのでしょう。

さて、velocityget にだけあるっぽい機能を移植していけば、差異が無くなっていくのかなぁ?

MTU 9000 での測定

そういえば、mtu 9000 のスループットも測定をしたかったで Intel Pro/1000PT を外付けしたんだっけなぁ。なので、測定してみた。

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

受信に関しては、ほぼ 1Gbps を使い切っている!凄し!

追記 (2009/10/06)

今回使ったスループット測定用のスクリプトmeasure_net_throughput.shをバックアップとして上げておく。

2009年9月27日

VT6122 の性能(2) - VIA Velocity の出自

velocitygetのソースを眺めていると VT3119 とか VT3216とか一見全く関係無さそうなチップ名らしき物が出てくる。 VT6122 の Device ID が 0x3119 なのでVIA内部型番になっているのかなぁ。 でも、ドライバ内では Rev ID での区別らしきものがあり、それに従うと VT6122 = VT3216 (?)っぽい。

正直のところ VIA に聞かないと分からないし、検索でもホンの僅かの情報しか引っ掛からないので、 憶測程度にしかならないが、ちょっとだけ書き残しておこう。

VT6110

ここら辺の事情は、ほんとに雲をつかむような感じだ。。。

ZyXEL社の Gigabit NIC (GN650-T/GN670-T) が最初の製品っぽい。そいつが VIA 内部では Device ID と関連づけて、多分 VT3119 と呼ばれていたんだろう。コイツにはまだ PHY が内蔵されておらず、ZyXEL の製品には PHY が載っている。それが CICADA製SimpliPHY のもの。

ZyXEL へのOEM供給?でチップの型番はZX1701Z/X1702になっているが、VIA が外販する時に VT6110 と付けたんだろうと推測できる。

参照
  1. BSD系のドライバ vgeには、ZyXEL 製のNICとVT3119 の記述がある。
  2. ZyXELのサイトには情報は殆どないが、Download Search で検索するととドライバ(rhineget 1.10/velocityget 1.18)が見つかる。
  3. ロシアでは結構流通した製品らしく、検索("Zyxel Omni LAN PCI G1")に出てくる。カード全体の鮮明な画像も出てくる。SimpliPHYのマークのチップが見てとれる。
  4. rhineget/velocityget 内の chip_info_table には、CHIP_TYPE_VT6110 のマクロがある。
  5. Gentooのフォーラムの記事に、GN650-T の lspciの出力があり、Rev 01 となっており、ソース内では REV_ID_VT3119_A1 に相当する。REV_ID_VT3119_A0 というのは開発版なのかなぁ。。。

VT6120/VT6121/VT6122

VT6110 に SimpliPHYを内蔵して1チップ化したものが、良く知っている VIA Velocity と呼ばれてる製品群で、 PCIのバスサイズが32bit/64bitのものがそれぞれがVT6120/VT6121で、VT6120 のパッケージを小型したのが VT6122 である。

内部的には VT3216 の型番が付いてると思われるが、ドライバが流用できるほど上位互換なので、Device ID が 0x3119 のままになったようである。

以後、Rev ID の範囲で区別する方針になったのか、0x00〜0x0F が ZX1701Z/X1702/VT6110 であり、0x10 〜 0x1F が VT6120/VT6121/VT6122 のどれかにあたる。ちなみに EPIA-EN12000EG に載っているのは 0x11 になっている。

性能アップのための機能で Tx/RX キューに関するなんかのタイマーが追加されている。

Rev ID が 0x20〜0x7fのもの

該当する製品が見つけられなかった。。。内部的には VT3284 の型番が付いていると思われる。

velocityget を読む限り、PCI のバースト転送に Memory-Read-Multiple が使えるようになったっぽい。なんのコッチャ、、、

Rev ID が 0x80 〜

PCIe に対応した VT6130/VT6132 が該当する。内部的には、VT3286 の型番が付いてると思われる。

どうも PCIe 化と同時に省かれた機能があるっぽいが、ドライバでは何も対処してないっぽい気がする。

まとめ

Device ID 0x3119 のデバイスは、Rev ID の範囲でチップを区別してるらしい(もしかしたら、特定の Rev ID リストが作れるかも)。

Rev ID内部型番チップ名
0x00 ~ 0x0fVT3119ZX1701Z/X1702/VT6110
0x10 ~ 0x1fVT3216VT6120/VT6121/VT6122
0x20 ~ 0x7fVT3284不明
0x80 ~ VT3286VT6130/VT6132

但し書き

元になるデータが凄く不確かであり、かなりの憶測が含んでいる(ほとんどが要出典)。あまり信用できる情報ではありませんのであしからず。

2009年9月24日

VT6122 の性能(1) - Linux のドライバの準備

VIA EPIA は不憫な奴だ。

去年から消費電力が低い Intel Atom ボードが出荷され、当初性能がわずかに上かなぁ〜と思われた後で、Dual-Core だとか Hyper-Threading とかが追加され、もう比べるのも可哀想なぐらい、次いでに Mini-ITX のボードの市場も荒らされまくり、踏んだり蹴ったりのボコボコにされてますなぁ、、、なんか違うかも。

何の気の迷いか EPIA-EN12000EG を買ってしまって以来、 不憫な奴が故に捨てられずに、年に1回くらいは思い出したように手を入れて使っている。。。はぁ〜

今回は NIC の性能について愚痴ってみよう。

EPIA-EN12000EG には VT6122 (Gigabit Ethernet) が搭載されている。Datasheet(pdf) を見る限り、South Bridge / VT8237R+ の下のPCIバス(32bit/33MHz)にぶら下がっている。PCIバス(32bit/33MHz) の上限 133MByte/s がボトルネックになるので期待は出来ない。PCIe 接続の VT6130/VT6132 でないなければ Gigabit の限界には迫れないが、どれくらい迫れるかが興味の有るところ。

二種類のドライバ

VT6122のLinux ドライバは二種類で、どっちも些細なバグが有る。

  1. via-velocity / kernel 本家に取り込まれているもの。性能が低いのがもっぱらの噂。WOL が動かない。
  2. velocityget / VIA 本家作成のドライバ。VIA AREA で公開されているが、ダウンロードページに辿り着くまでが迷路というか、ほんとに無理。現在(2009/09/23)の時点で、1.36 が安定版らしい。 rmmod/insmod を繰り返すと dmesg に 不審な oops を残す不具合あり。
で、修正パッチを作ってみた。
  1. via-velocity の WOL 対応パッチ (debian lenny/kernel-2.6.26用) / via-velocity-fixed-wol.patch
  2. velocityget の procエントリのリークフィックパッチ / velocityget-fixed-proc.patch

via-velocity単体で再構築

via-velocity 単体だけでも再構築できるようにしてみよう。ターゲットは、Debian lenny の 2.6.26-2-686 向けだが、他のディストロでも応用可能かなぁ。

# apt-get install linux-headers-2.6.26-2-686
# apt-get install linux-source-2.6.26

構築用ソースのかき集め

  1. 適当にでっち上げた Makefile / Makefile-via-velocity-only
  2. linux-source-2.6.26 パッケージからvia-velocity.[hc]
# 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
あとは再構築してモジュールをインストール。
# cd via-velocity
# make install
make -C /lib/modules/2.6.26-2-686/build SUBDIRS=/usr/src/via-velocity modules
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.26-2-686' に入ります
  CC [M]  /usr/src/via-velocity/via-velocity.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/via-velocity/via-velocity.mod.o
  LD [M]  /usr/src/via-velocity/via-velocity.ko
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.26-2-686' から出ます
mkdir -p /lib/modules/2.6.26-2-686/kernel/drivers/net
*****  Move current driver via-velocity.ko to via-velocity.ko.2009-09-24-1253781710 file
mv /lib/modules/2.6.26-2-686/kernel/drivers/net/via-velocity.ko /lib/modules/2.6.26-2-686/kernel/drivers/net/via-velocity.ko.2009-09-24-1253781710

install -m 644 -o root via-velocity.ko /lib/modules/2.6.26-2-686/kernel/drivers/net
/sbin/depmod -a || true
最後に rmmod/modprobe してモジュールを更新して完了。

これで機能的には同程度になったので、性能比較でもしますかぁ。

追記 (2009/09/26)

どうも via-velocity には、ネットワーク負荷が高いときにシステムが黙りをする症状(1,2 等々)?が報告されている。velocityget を使えば症状が出ないので、velocitygetを使うべしとなってるらしい。。。

ソースを見比べると、割り込みハンドラ内の処理が問題のようだ。それぞれは、大まかに次のようになっている。

  • via-velocity
    1. 未処理の割り込み要因がなくなるまでループする
    2. ループの一単位は、受信/送信ディスクリプタをそれぞれ最大15ディスクリプタ分を処理する
    3. 処理したディスクリプタ数が int_works を超えたらメッセージを出力する
  • velocityget
    1. 受信/送信ディスクリプタをそれぞれ最大int_worksディスクリプタ分を処理する
    2. 上記の処理を2回繰り返す

要するに via-velocity では int_works の取り扱いが杜撰で、かつネットワーク負荷が高いと割り込みハンドラ内に捕われてしまう。なので、割り込みを共有してるデバイスの処理が滞る症状が現れる。

他のネットワークチップのドライバーを見る限り、割り込みハンドラ内で全部のディスクリプタを処理せずに抜ける実装は多々有るので、バグなんだろうなぁ。

うんで、修正パッチを作ってみた

  1. via-velocity の int_works 関連の修正パッチ (debian lenny/kernel-2.6.26用) / via-velocity-fixed-int_works.patch

上のWOL対応パッチの後に当てればいい

# tar xfz via-velocity-buildpack-nosrc.tgz
# 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
# cd via-velocity
# make install

これで、本当に不具合が無い状態?になったので、性能比較でもしますかぁ。

追記 (2009/09/29)

どうも via-velocity-fixed-int_works.patch の velocity_tx_srv の修正部分がバグってたみたいだ。なので、修正版に差し替えました。申し訳ない。

2009年7月21日

Linux でボリュームを暗号化する (3) - 性能比較

ボリュームを暗号化する上で気になることは、どれくらいIOの性能が落ちるかである。

普通にそこら辺にある2台でベンチを取ってみた。

  • ASUS M2NPV-VM / Athlon64X2 3800+ (2GHz) / DDR2-533 1G x 4
  • EPIA-EN12000EG (C7 1.2GHz) / DDR2-533 1G
暗号化するのは、ちゃっと起動用とは別に確保してた SATA 320G HDD(ST3320620AS) を使った。次いでなので、VIA PadLock の有無も比較してみた。

測定は hdparm -t を使って3回で最も良い値を使った。

読み込み速度(MB/sec)
M2NPV-VM (2GHz) - 素74.82
M2NPV-VM (2GHz) - cryptoあり71.650.96
M2NPV-VM (1GHz) - cryptoあり36.100.48
EPIA-EN12000EG - 素76.04
EPIA-EN12000EG - cryptoあり/PadLock 有43.260.57
EPIA-EN12000EG - cryptoあり/PadLock 無12.640.17

格段に劣化する訳では無さそうで、 ファイルシステムが絡めば DiskIO と暗号化処理が並列化しそうなので、 気にならない程度に落ち着くのかなぁ。。。

あと VIA PadLock は結構効果があり、in-order 1.2G だけだと非力なのかぁ?

Intel Atom だとどの程度になるか気になるなぁ〜。。。それとも Atom 系に AES-NIが実装されるのを気長に待つ方がいいのかなぁ。。。

修正(2009/09/08)

Athlon64X2 は cpufreq の ondemand governor を使ってたため、どうも結果が怪しかったので、クロックを固定して再度計測し直した。

結果、Athlon64X2に関しては 結構クロック周波数に比例した性能であり、2GHz 程度の性能があれば汎用CPUには苦にならないようである。C7は PadLock を使うとやっと一人前であるが、他を凌駕する性能とかは無さそうだなぁ。。。

2009年4月21日

ファイルサーバのHDDを省エネHDDに変更

VIA EPIA-EN が安定運用?の見込みが出てきたので、ちょっくら省エネを追求してみた。

今使っている Mini-ITX ケースは、「Be Silent GAWA6200」で、今使っている EPIA-ENシリーズにまさに対応しており、ファンレス運用が可能。ただ、どうも安定しないので12cmファンをぽこっと載せ、風量を確保する為に、エアフロー用の金網部分を外していた。するとちょうどいい具合に、オンボードの SATA ポートにアクセス出来る。なので、eSATA接続の外付けHDDが使える!!

P1010640

eSATA接続の外付けHDDは、USB接続みたいに速度が出ないことは無く、各社多様に製品群が発売されており、いろいろ選べてお得だし!安いし!速いし!良いこと尽くめ!

交換可能で静かなのが欲しいので、「LogitecのLHR-DS02SAU2」とWD10EADSの組み合わせを選んでみた。


"Logitec クレードルタイプ HDDリーダー/ライター LHR-DS02SAU2BU" (ロジテック)

さっと入れ替えてみると、、、アイドル時に約23W程度で、かつHDD が spindown? すると 20W 弱。負荷をかけても 30 W程度くらい。

P1010639

いい感じだぁ。全部が収まる Mini-ITXケースがあればいいのかぁ。

2009年4月13日

VIA EPIA-EN で watchdog を設定

iPod Touch のアプリに某掲示板の専用ビューア BB2C がある。 結構使い勝手が良いので、最近ぱらぱら見るようになった。 その中で、自作PC板の低消費電力なんとかスレッドを覗いたら、 PCのアイドル時の消費電力が 20W〜30W の報告があり、10Wとかもある。 ちょっとビックリ。

なんやかんやで、ここ2年くらいCPUもマザーボードも買っていないので、 すっかり取り残されてしまったようである。 手持ちのパーツの Athlon64X2 3800+/M2NPV-VM/DDR2-800 2Gx4 を組み合わせて、 アイドル時の消費電力が 70W となど浮かれていたのは、どうも井戸の中の蛙だったようである。

はぁ〜〜。金欠だし、どうしてくれようかぁ

しょうがないので、箪笥の奥に眠っていた EPIA-EN12000EGを引っ張りだしてきたのだが、 コイツは Linux では時々ちょっと原因不明のハングアップして常時運用とか向かないので ゴミかなと思っていた代物である。

動かせるように組み直して計測してみると、アイドル時の消費電力が 15Wくらいである。 某 Early2009 とほぼ同じ。でもあっちは Core2Duo 、、、懐が淋しいので我慢しよう。

P1010634P1010635

最新のカーネルであれば、問題が修正されているかと思って様子を見たが、 頻度は多くないがハングアップする現象はあるようである。

マニュアルには「Watchdog Timer」の記述があり、コイツがなんとかできればハングアップしても強制再起動ができ、常時運用が出来そうである。

、、、えっと、ドライバはどれ?

ググるところ、小一時間。下記のURL のフォーラムにズバリの回答があった。
tkArena Forums > VIA Arena > VIA EPIA (Mini-ITX, Nano-ITX, Pico-ITX) Arena - hardware watchdog

Super I/Oチップの w83697hf に watchdog timer が実装されており、そいつがどっかにリセットのシグナルを出すらしい。

watchdog モジュールのロード

EPIA-EN12000EGの場合、watchdog はデフォルトI/Oポートにいないので、 w83697hf_wdtをロードしても、次のようなログが残り使えない。

[   30.529537] w83697hf/hg WDT: WDT driver for W83697HF/HG initializing
[   30.529550] w83697hf/hg WDT: Looking for watchdog at address 0x2e
[   30.529573] w83697hf/hg WDT: watchdog not found at address 0x2e
[   30.529580] w83697hf/hg WDT: No W83697HF/HG could be found

なので watchdog の I/Oポートを検索するために、wdt_io=0 を指定してロードすると、結果がdmesgに出力される。

[  202.597226] w83697hf/hg WDT: WDT driver for W83697HF/HG initializing
[  202.597241] w83697hf/hg WDT: Looking for watchdog at address 0x4e
[  202.597260] w83697hf/hg WDT: watchdog found at address 0x4e
[  202.597401] w83697hf/hg WDT: initialized. timeout=60 sec (nowayout=0)

再起動後に発見したI/Oポートを探すように、/etc/modprobe.d/local に書き出しておく。

options w83697hf_wdt wdt_io=0x4e timeout=60

watchdog パッケージの設定

Debian lenny なので、パッケージをサクッとインストールする。

# apt-get install watchdog

/etc/default/watchdog にモジュールの指定を書く。

watchdog_module="w83697hf_wdt"

今回は死活のみを監視するので、 /etc/watchdog.conf は下手にいじらないで次の行のみ有効化する。ただ、watchdog自体の負荷が気になるならば interval を多めに取ればいい(ドライバ指定のtimeout以下になるように)。

watchdog-device	= /dev/watchdog

watchdogデーモンを立ち上げると完了する

# /etc/init.d/watchdog restart

watchdog の確認

あぁ、、、「killall -9 watchdog 」で暫くして強制再起動がかかれば確認完了。。。

まとめ

なにげにSSD-IDEを載せたので、内蔵ストレージに書き込みが頻発するのは避けたい気がするので、箪笥の中から掘出した3年ものの外部ストレージをつけてみた。

P1010636

なに!PCの同じだけ電力を食うのかこの外付けHDDは!

なにげに、VIA EPIA-EN を使いこなしているような気がする。

2008年4月25日

Debian で VIA の PadLock を使ってみる

以前持っていた EPIA-ME6000 が不幸なことに再起不能になってしまった。直ぐにEPIA-EN12000EGを入手してたのだが、当時のLinuxのSATA_VIAドライバは不安定だったので、放ったらかしにしていた。

症状として、立ち上げ直後は問題ないが、それからしばらくするとディスク関連でエラーを吐いてフリーズしてしまい、長時間運用ができない、、、何じゃこれって感じ。

最近(etch/lenny ともに最新版)試したところ sata_via は非常に安定している気がする。

VIA C7 Esther には、ハードウェア処理のAES暗号化、SHA関数、乱数生成といった目玉な機能が実装されている。

なんで、Linux で使いましょう。。。。

参考 VIA PadLock support for Linux

ハードウェア乱数生成

Debian etch/lenny の Linux 2.6.18/2.6.24? ともに十分なサポートがあり、rng-tools を使うと、/dev/random からの乱数生成の帯域が太くなるらしい。

apt でインストール

# apt-get install rng-tools

設定を行い

/etc/default/rng-tools

...
RNGDOPTIONS="--hrng=via"
...

/etc/modules

via_rng

rngd を立ち上げ、動作確認をする。

# /etc/init.d/rng-tools stop
# dd if=/dev/random of=/dev/null bs=512 count=1000 & pid=$!
# sleep 10 ; kill -USR1 $pid ; sleep 1 ; kill $pid
0+0 records in
0+0 records out
0 bytes (0 B) copied, 10.0067 seconds, 0.0 kB/s
# /etc/init.d/rng-tools start
# dd  if=/dev/random of=/dev/null bs=512 count=1000       
0+1000 records in
0+1000 records out
96169 bytes (96 kB) copied, 1.04326 seconds, 92.2 kB/s

/dev/random に十分なエントロピーが供給されているので、ブロックされることは殆ど無くなる。

VIA Padlock for Linux Crypto API

VIA Padlock は Linux 2.6.19 からフルサポートされる。素のDebian etch のままだと 2.4.18 止まりなのだが、最近 etch-proposed-updates にバージョンに etchnhalf が含まれる linux-image が提供され、こいつが最新カーネルバージョンに追随してるっぽい。なので、etch でも 2.6.24 が使えるのでこいつを使う。

# apt-get install linux-image-2.6-686-etchnhalf
# reboot
...
# uname -r
2.6.24-etchnhalf.1-686

VIA Padlock のモジュールを読み込むように設定

/etc/modules

padlock_aes
padlock_sha

リブートして

# grep driver.*padlock /proc/crypto
driver       : sha256-padlock
driver       : sha1-padlock
driver       : cbc-aes-padlock
driver       : ecb-aes-padlock
driver       : aes-padlock

カーネルで使える暗号化処理 AES/SHA が高速化するらしい。IPSec 、dm-crypt、とかが、、、

# dd if=/dev/zero of=/dev/ram1 bs=1024 count=5x1024
5120+0 records in
5120+0 records out
5242880 bytes (5.2 MB) copied, 0.0236812 seconds, 221 MB/s
...
# modprobe padlock_aes
# cryptsetup create -c aes-cbc-essiv:sha256 -d /dev/random ram1 /dev/ram1
# dd if=/dev/zero of=/dev/mapper/ram1 bs=1024 count=5x1024
5120+0 records in
5120+0 records out
5242880 bytes (5.2 MB) copied, 0.142272 seconds, 36.9 MB/s
# cryptsetup remove ram1
# rmmod padlock_aes
...
# modprobe aes_i586
# cryptsetup create -c aes-cbc-essiv:sha256 -d /dev/random ram1 /dev/ram1
# dd if=/dev/zero of=/dev/mapper/ram1 bs=1024 count=5x1024
5120+0 records in
5120+0 records out
5242880 bytes (5.2 MB) copied, 0.902938 seconds, 5.8 MB/s
# cryptsetup remove ram1
# rmmod aes_i586

VIA Padlock を使った方が 6倍くらい速くなるらしい。。。

これでユーザランドで高速化されるかと言うと、Linux Crypto API は、userland にはインタフェースを持っていない。。。パッチは2種類(CryptoDev for Linux,OCF-Linux)あるらしいが、いまだに議論があるらしく、マージされてない。

OpenBSD/FreeBSD だと OpenSSLが CryptoDev を使うようになってるので、何もせずに高速化されるらしい。。。いいなぁ。

VIA Padlock for OpenSSL

Debian etch/lenny ともに、VIA Padlock の engine が有効にして構築されていなので、自前で用意する必要がある。どうも共有ライブラリの形でプラグイン化できないのが駄目らしい。

VIA PadLock support for Linux 内の以下のパッチを当て、パッケージを再構築。

  • openssl098-padlock-shared-move.diff
  • openssl098-padlock-shared-makefiles.diff

インストール後、/usr/lib/ssl/engines/libpadlock.so がインストールされる。

# openssl speed -evp aes256            
Doing aes-256-cbc for 3s on 16 size blocks: 1847840 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 575493 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 154125 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 39230 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 4929 aes-256-cbc's in 3.00s
...
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc       9855.15k    12277.18k    13152.00k    13390.51k    13459.46k
# openssl speed -evp aes256 -engine padlock
engine "padlock" set.
Doing aes-256-cbc for 3s on 16 size blocks: 10478263 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 8095021 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 256 size blocks: 4480017 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 1600314 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 228568 aes-256-cbc's in 3.00s
...
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      55884.07k   173271.35k   382294.78k   546240.51k   624143.02k

via_rng/padlock_aes の効果で、実に約46倍速くなるらしい。。。はや。

OpenSSL を使う奴のほとんどが簡単なパッチを当てる必要があるらしい。そのうち改善されていくのかなぁ。

OpenSSH にパッチを当てて VIA Padlock を有効にした場合、

 ...  ssh/sshd ともにソフトウェアバージョンを利用 ...
# dd if=/dev/zero count=50 bs=1M | ssh -c aes256-cbc localhost "cat >/dev/null"
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 11.8916 seconds, 4.4 MB/s
 ...  ssh/sshd ともに padlock engine を利用 ...
# dd if=/dev/zero count=50 bs=1M | ssh -c aes256-cbc localhost "cat >/dev/null"
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 7.88281 seconds, 6.7 MB/s

約 50 % の高速化かぁ。。。

さて EPIA-EN12000EG をどう活用しようかなぁ。

2006年11月10日

EPIA-ME6000 のコンデンサが破裂

Mini-ITX用のケースがGAWA6200が売り出されたので、ここ2〜3年使っていなかったEPUA-ME6000用に購入してみた。

で、組み立てて火入れをしてみると、気持ち良いほど今壊れましたって具合に「パン、パン」と目の前でコンデンサが破裂した。正直、ビビッた。

blog20061110-2
blog20061110-1

GSC製電解コンデンサの破裂、、、よくあるらしい。破裂した以外にも20個ぐらい同じようなコンデンサが載っている。

もうゴミ箱行きかと思うが、貧乏性なので何とか直そうかと思う。

久しぶりの投稿

かなり期間が空いてしまったが、ブログを再開してみようと思う。 2013年3月が直前の投稿だったが、頻繁に更新していた時期が 2011年11月までなので、8年間ぶりとなる。 8年間なにをしていたのかと言えば、2回転職して未だにIT技術者の職を得ている。 その...