e1000eが来た。 ~ベンチマーク編~

 さて、前回さりげなくPRO/1000と書いてしまったが、その通り。ついにPRO/1000が来ましたよ。
 というか、当初の予定ではお流れ(笑)の筈だったのだが、VLAN周りのトラブル発生で急遽導入されたというか。

 しかも「どうせなら新しい方がいいや」という超テキトーな理論により、単品カードとしては出たばかりのe1000eの方を入手(オンボードでは少し前から出てるよね)。
 あ、勿論デスクトップ版ですが何か(汗。

 ということで、早速ベンチ。見せて貰おうか、Intelの実力とやらを。

From To SEP OFF SEP ON
Yukon e1000e 840 Mbps 200 Mbps
r8168 e1000e 750 Mbps 200 Mbps
e1000e Yukon 830 Mbps 210 Mbps
e1000e r8168 800 Mbps 210 Mbps
e1000e e1000e 690 Mbps 210 Mbps

 そいや前回書き忘れたが、パラメータは以下の通り。
 netperf -H -l 30 — -s 65536 -S 65536

 ・・・えっと。
 e1000e対向が妙に遅いんですが。何だコレ。

 それならば、取り敢えずRWIN拡大効果を見てみましょ。
 netperf -H -l 30

From To SEP OFF
e1000e e1000e 850 Mbps

 ・・・にしたって遅過ぎやしないか。これだけ世間で信仰を集めているIntelが。
 あ、念のため、設定は結構詰めてますよ。というか、デフォだとe1000e対向で500Mbpsしか出ないので。

 それでは次、CIFSの転送速度実験。

From To SEP OFF SEP ON
Yukon e1000e 250 Mbps 210 Mbps
r8168 e1000e 280 Mbps 240 Mbps
e1000e Yukon 260 Mbps 240 Mbps
e1000e r8168 260 Mbps 220 Mbps
e1000e e1000e 310 Mbps 240 Mbps

 ・・・こんなもの、なのか?

 ということで、取り敢えず数字を取るのに疲れたので続きは次回。

Share

もうIntel以外(のGbEは)駄目かも分からんね。

 ・・・というのは、ですね。
 具体的に何が起こったかと言いますと。

 まず、事実の確認。
 YukonはVLANが作れます。
 そして、WindowsでVLANアダプタを作ると、画面上はNICがいっぱい増えているように見えます。ちょっとお得な気分。

 で、ここからは発生した問題。

 VMware BridgeをYukonのVLANアダプタにかましても、ウンともスンとも言わないのですが。全く外と繋がらないのですが。

 ・・・えと、これね。自分が何かミスしたのかって、本気で全部イチから確認しましたよ、冗談でも何でもなく。でも、どう見てもミスは無い。
 で、最後にまぁついでにという感じで、Intel PRO/1000を挿して(勿論Desktop版)同じことしてみたら何の問題も無く動いてしまったという。

 まぁ、そもそもVLANアダプタ作成の段階でYukonはイマイチ挙動が怪しい風味ではあったのだけど。
 まさか、ウンともスンとも言わないなんて不具合があるとは。

 しっかし・・・遅いだけなら兎も角、その上病気持ちときたら、Yukonの立つ瀬は何処に・・・。

 確かに蟹はシステム負荷は高いが、もしこれで安定度と速度でメリットがあるなら、Yukonより余程良い選択肢のような気さえするのだが。
 とはいえ、当方r8168でVLAN使えるドライバって見たこと無いんだが。そもそも存在するのか?

 つーか、全力でIntel回避を日々実践している当方をして、%TITLE%な発言をさせるなんて・・・
 真面目な話、Intel以外で真っ当なGbE NICってのは無いんかい。

#ちなみにIntel製アダプタを以ってしてもHost側にSEPが導入されているとVLANにBridge出来ないですな。
 原因は分かり易くて、本来「VLAN:VLANID」と見えないといけないVMWareのVMNet設定画面に「Teefer2 Miniport」なんてのが見えてるのでね・・・。

Share

Yukonって根本的に遅い?

 さて、前回のネタでYukon→Yukonが妙に遅いという結果が出てしまったのだが、これが果たしてnetperfだけのものなのか、それとも実際にCIFSで影響するのか、ちょこっとテスト。

 環境は前々回と同じ、つまりnvlan→nvlanで980Mbps@SEP:OFFとか出ていた環境。
 netperfでなくCIFSの実ファイル転送(10GB@xcopy)にて計測、と。
 但し例によっていろんなスキマを狙ってなので、比較対象がr8168(蟹8111)だけ。

 ・・・ところが、その対蟹だけでも目に見える差が。

From To SEP ON SEP OFF
Yukon Yukon 195 Mbps 220 Mbps
Yukon r8168 210 Mbps 240 Mbps
r8168 Yukon 250 Mbps 290 Mbps

 ちなみにどちらもJumboFrame有効(9014byte/9Kbyte)で、Yukonの方はTX/RX bufferを初期値の256byteから512byteに変更済。
 この設定変更で5~10%ぐらいは転送速度が上がるのがポイント。

 で。
 え゛~っと、Yukonってそんなに遅いの?ドライバ設定変えても、それでもまだ蟹以下なんて。

 但し、明らかに蟹の方が負荷は高い。これは目測ぱっと見で分かるぐらい違うので、転送効率(という言い方をするのか知らないが)という意味ではYukonの方が優秀。
 辛うじてコレだけが救いかね。

 あと、CIFSが遅いだけあって?SEPの影響はそこまで強烈でもないが、それでは影響無いかというと全然そんなことはないという。

 ◇

 ・・・というか、SEP OFFの時にも妙に遅くないか?
 これはもしかしてアレか、RWINの呪いか。

 ということで、RWIN=1MBにレジストリを書き直してリトライ。

From To SEP ON SEP OFF
Yukon Yukon 240 Mbps 280 Mbps
Yukon r8168 230 Mbps 310 Mbps
r8168 Yukon 290 Mbps 290 Mbps

 ありゃん、またしても一目では理解しにくい数字が。
 まず一つ、r8138はやはり重い、というかSEPの影響を大きく受ける。これは以前のNetPerfの数字と傾向は一緒なので、まぁ良し。

 逆に、r8138→Yukonで、SEP On/Offで数字が違わないのは謎。コレ、数字見間違いかと思って何度もやってみたのだが、間違いなくこの数字。なんでだろう。

 そして、全体通しての結果。確かに数字は改善されたが(1MBは2008とVistaとでは標準の筈、2003とXPでは64KB)、それにしたって遅過ぎやしないか、これは。PCI-Expressの帯域ナメとるのか。

 どうやらそう簡単にお手軽に解決出来る場所にネタは無いですか。
 ここのCIFSが妙に遅いのは何か根本的に間違ってるってことですかね。
 これはまた調べないといけないネタっぽいが、さて何時出来ますかね・・・。

 ◇

 ちなみに、近日中にe1000が(こそっと)試せることになりそうなのだが、個人的にはe100は兎も角e1000は出来がいいとは思えないのよ。

 ただ、他があまりにも駄目なら相対的に出来は良いということになるし。
 いくら「Intelは全力回避」が信条だからって(ぉぃ)、他に選択肢がなければ回避不能なワケだし・・・。

 まぁここで「仕方ないので(あくまでIntelを拒絶して)寂しい人生を送る」とかいう選択肢が出てこなくなっただけ、自分も進歩したなぁとか(爆。

 そういう意味では、最近国内でもやっと出回り始めたe1000eの方はどうなんだろう・・・消費電力はガクンと減って漸く「並」になったっぽいけど、それ以外はまだ何の情報も集めていないしなぁ。

Share

BCM5721をベンチしてみた。

 前回の続きネタ。

 一部でやたら評判が良いBroadcom製チップ、BCM5721を試せる環境を(ほんの少しだけ)触れたので、前回と同じようにNetPerfにてチェックしてみた。

From To
Yukon tg3 550 Mbps
Yukon Yukon 430 Mbps
tg3 Yukon 700 Mbps
tg3 tg3 750 Mbps

 まず、前回とはかなり環境が違うので数字を見比べること自体が不可能。
 一番大きな違いとして、今回の方がCPU周りが1ランク以上ヨワい。
 次、BCM5721の制限によりJumboFrame無効。
 最後に、SEPどころかAntiVirusやFirewallの類は何も入っていない。

 とはいえ、目に付くのはYukonの数字の低さ。CPU負荷を見てる限りではまだ余力を残しているように見えるのだが、やはりこれはチップ自体が遅いということか。
 そして、Yukon→Yukonの速度の落ち方は異常。相性なのか、ドライバの問題なのか、それとも単なる駄目駄目チップなのか。

 #ちなみに、JumboFrameを有効にしてみるとYukon→Yukonでも570 Mbpsと数字はかなり改善、CPU負荷も目に見えて減少。 Yukonに関してはやはりJumboFrameさまさまですな。

 一方、世間で評判の良いtg3(Broadcom 5721)だが、確かにYukonと比べると圧倒的な速度を叩き出している。1514byteのパケットでも、対向では750Mbpsという数字が。
 但し、CPU負荷という意味では、送受信共にnvlan等と大差ないような印象。素性は悪く無さそうだが、既に世代的に古くなってきているというのはあるのかも。

 #実はテスト時に受信側CPU負荷は100%に到達してしまっていたので、CPUがもっと良ければ速度はもっと出た可能性大。世間では950Mbpsとかそういう数字も言われているし。

 ◇

 今回のまとめ。
 ・Yukonはやっぱり遅ぇ。
 ・tg3は悪くはない。

 とまぁ、こんなところで。
 ・・・そろそろIntelとVIAも試したくなってきた。どっかに転がってないかな、と。

Share

Symantec死ぬほど遅いよ伝説。

 某所のネットワークについて、以前から気になっていたこと。
 折角ネットワークがGbEで統一されているというのに、何故か速度が出ない。
 構成的にはCIFSの実効で50MB/Sぐらい出ても全然問題ない筈なのに、せいぜい20MB/Sぐらいしか出ない。

 何でやねん。
 ということで、怪しい要素をチェックしてみた。

 その1。NICがIntelやBroadcomではない。
 その2。Symantec Endpoint Protection(11.0 MR3)が導入されている。

 ということで、スキを見て実際測ってみた。

 ◇

 検証はよくあるNetPerfでのベンチ。
 環境のタイミングの関係で内容に偏りがあるのは勘弁。

From To SEP ON SEP OFF
Yukon nvlan 240 Mbps 700 Mbps
nvlan Yukon 240 Mbps 900 Mbps
r8168 nvlan 210 Mbps 950 Mbps
nvlan r8168 220 Mbps 950 Mbps
nvlan nvlan 240 Mbps 980 Mbps

 ※全ての環境で9KB JumboFrameが有効。

 ・・・えっと。
 少なくとも、ファイルサーバとして使いたいならSEPを導入してはいけません、と読めるのは気のせいでないよな?

 気になることといえば、パフォーマンスメータを見てるとCPUの1コアが殆ど飽和している(もう一つはかなりヒマしている)。CPUの1コアがもっと速ければ、SEP有効でももう少し速度出る、のかね。

 目先を変えて、チップ別に見ると。

・蟹(RTL8111C)はNetPerfでは速度が出るが、SEP有効ではイマイチ。
 あと、CPU負荷がやや高いようだが、大差というワケでもない。

・Yukon(88E8053)はSEP有効では蟹より速いが、NetPerfでは遅い。
 CPU負荷は並だが、そもそも遅い、と。

・nvlan(MCP55S)は、割と真っ当に見える。

 nvlanは兎も角、蟹もYukonもコレではちょっと。
 やっぱりBroadcomかIntel挿せ、ということかね。

 ◇

 今回のまとめ。

 ・蟹は重い。
 ・Yukonは遅い。
 ・SEPは死ぬほど遅い(泣。

 ◇

 今回のおまけ。

 その1、MR2 MP2の環境が(間違って)取り残されていたので持ってきてみた。

From To SEP ON SEP OFF
Yukon nvlan 200 Mbps 670 Mbps
nvlan Yukon 200 Mbps 850 Mbps

 結論、さっさとMR3にすべし。

 その2、Jumbo Frameは既に迷信なのかどうか、試してみた。

From To SEP ON SEP OFF
r8168 nvlan 210 Mbps 820 Mbps
nvlan r8168 205 Mbps 700 Mbps
nvlan nvlan 215 Mbps 710 Mbps

※JumboFrame無効に設定。

 SEP有効時ですら、スループットに有意な差が出てます。無効にしたら差は歴然。
 そして更に、この数字を出した時のCPU負荷が全然違うのがポイント。

 ・JumboFrame ONの時は送受信共にCPU負荷が50%程度(おおよそ)
 ・JumboFrame Offの時は受信側が70%程度(目測)、送信側は90%~100%

 速度面での差は小さいが、システム負荷の差は強烈。
 結論、JumboFrameが使えるなら使うべし。

Share