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の方はどうなんだろう・・・消費電力はガクンと減って漸く「並」になったっぽいけど、それ以外はまだ何の情報も集めていないしなぁ。
Tags: GbE NIC
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も試したくなってきた。どっかに転がってないかな、と。
Tags: GbE NIC
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が使えるなら使うべし。
Tags: GbE NIC
そしてもっさりは消えた、のだが・・・。
HDMIセレクタにハンダを入れた挙げ句、無事、HDMI接続によるDualDisplay環境が出来上がった780G。
巷で言われている「Dualにしたらもっさりが消えた」というウワサを確かめて、780Gネタ最終回としましょう。
ということで、まずベンチ・・・。
| VGA | GDI | Text | Square | Circle | BitBlt |
|---|---|---|---|---|---|
| 780G DualDisplay | 4774 | 136 | 2565 | 1270 | 803 |
| VGA | D2D | 10 | 100 | 500 | 1000 | 5000 | 10000 |
|---|---|---|---|---|---|---|---|
| 780G DualDisplay | 1774 | 105 | 90 | 54 | 36 | 10 | 5 |
えと、何これ（笑。GDI速度、Singleの時より圧倒的に上がってるんですけど。
更に、Singleの時は「こいつはすげぇ」というレベルでもっさりしていたWebを開いてみても、全然もっさりしてないんですが。普通にサクサク行けるよ？
ということで、Dualにするともっさりが消える、というのは事実でしたとさ。
◇
しかしこうなると、原因は何じゃらほい。
普通に考えると、Dualにすると描画面積が増えるのでパフォーマンスには負の影響が出る。
8500GTや7600GSを使ったベンチテストでもその通りの数字が出ている。
だというのに、数字が上がる。体感で分かるぐらい動きが良くなる。
以前PowerPlayが原因だという話もあったが、実際にAMD OverDriveで見てみたところ、このM/BではGPUは500MHzで固定の様子。
数字がぴょこぴょこ変わりまくるのを期待していたのに、実につまらないというかなんというか。
こうなると、考えられる原因はただ一つ。ドライバが駄目、以上。
まぁ確かにベンチ取ってみると絶対値が低めということもあるが、Dual時は少なくとも「体感では」問題ない。
そうなると、Single時のドライバの挙動に問題があるとしか思えない。
◇
で、ここまで書いてふと思いついた・・・。思いついただけで何の証拠も無いのだが。
もしかしてCatalyst、Single Display時には780Gの2Dアクセラエミュを使い、Multi Display時には全部CPUが面倒を見る、なんて構造になっていやしないだろうか。
そして、780Gの2Dアクセラエミュは死ぬほど遅いので、CPU丸投げ状態のMulti Display時の方がCPU負荷は上がるものの快適に動く。
何でこんなことを思いついたかというと、もっさり問題解消のためにある設定が効くという話があるので。
具体的にはWindowsの設定のDisplayのところにある「ハードウェア アクセラレータ」スライダを一番右（普通）から一つ下げるというもので、確かにこれ効くんですよ、試してみたら。
で、コレは文字通り、ハードウェアが持っている機能（の一部）を使わなくする設定なんでね。
Radeon HD世代からは、単体ボードですら2Dが遅ぇ！という話が時々聞こえてきたりもするし。
統合型でメモリ帯域もダイ面積も限られている780G（HD 3200）ではその影響は更に大きくて、という解釈も個人的には出来なくもない、ですな。
2Dベンチネタ、最終章。
さて、このところうだうだと続いてきた2Dアクセラレーション絡みのネタ、今回が最終回ですよ。
＃もっさりネタは続きます。
というのは、秋葉原をうろうろしていたら、かなり状態の良い中古のGeForce 7600GTが激安になっていたので、思わずゲットしてしまったので。
2D（GDI）のハードウェアアクセラレーションを装備した最終世代GeForce、7シリーズの中堅モデルですな。
＃実は購入の決め手は2Dがどうこうではなく、DualDVIなVGAがこの値段で買えたから、だけど。
ということで、部屋に戻って早速ベンチ。VGAとドライバ（ForceWare90）以外の環境は以前の8500GT／8400GSの時（ForceWare176）と一緒なので、見比べてみて下さいな。
| VGA | GDI | Text | Square | Circle | BitBlt |
|---|---|---|---|---|---|
| GeForce 7600GT | 11484 | 1156 | 3393 | 3125 | 3610 |
| GeForce 7600GT DualDisplay | 8166 | 1118 | 3006 | 2719 | 1323 |
| VGA | D2D | 10 | 100 | 500 | 1000 | 5000 | 10000 |
|---|---|---|---|---|---|---|---|
| GeForce 7600GT | 9440 | 611 | 540 | 318 | 199 | 52 | 27 |
| GeForce 7600GT DualDisplay | 8710 | 583 | 522 | 308 | 178 | 48 | 24 |
GeForce 7世代＋2桁ドライバの効果てきめんなのがDirect2D。こりゃすげぇや。
あと、前回と違ってD2DベンチでもDualDisplay有効化で数字が明らかに変化したので別に記録。
一方、GDI周り。TextとCircleの速度はさすがGDIアクセラレーションが効いてるだけあるが、Squareは逆に遅くなっている。
そして、BitBltの速度はやや良いものの、激差ということでもない。
◇
以上の結果とネット上に数多ある各種ベンチ結果と突き合わせた結果、自分の中で出た結論。
GDIアクセラレーションについて。確かに文字描画等はハードウェアアクセラレーションを持ってた方が圧倒的に有利だが、四角描画では逆にCPUに仕事させた方が速かったりする。
総合的に見ると、GDIアクセラレーションの有無にこだわる必要は無いと思われる。
但し、最近のRadeonに見られる妙に遅かったり一部機能がバグってたりというのは論外。・・・つかどうせドライバのバグだろ？とっとと直せや＞AMD。
BitBltについて。メモリ速度も多少影響はあるが、それよりメモリ幅が圧倒的な意味を持つ。VRAMメモリ幅が64bitは核地雷、逆に 256bitあるGF9600GT（ファンレス限界・・・補助電源要るけど）ではもう一ランク上が狙える。
但し、こちらもRadeonは・・・う～ん。つ～か、ドライバの品質はホントどうにかならんのか・・・
Direct2Dに関して。もう泣く子もキレる（何だそれ）違いが実際にあります、としか言い様がない。
ごく限られた用途とはいえ、目的によってはD2Dのパフォーマンスが実際に大きく影響する場面も存在するので、そういう場合はやはり「古めの一品」を掘り出すしかない。
・・・以上をまとめると、こうなる。
Direct2Dを本気で使う「よっぽど特殊」な環境でもない限り、WindowsXP環境を理由にGeForce 7シリーズやRadeonX1シリーズを選択する理由はない。
但し、「よっぽど特殊」な環境では、やはりGF7やRadeonX1に価値はある。
ということで。
◇
個人的に一番意外だったのは、メモリクロック400MHzと700MHzという圧倒的な速度差が、2D周りのベンチでは殆ど見えてなかったこと（無いワケではないけど）。
少なくともGeForce系の場合、128bit／400MHz DDRってのは「世間的に恥ずかしくない最低限度の2D速度」を確保するのに丁度いい目安、なのかも。
◇
以下、12／5追記。
色々いじっていたらうっかり（笑）ForceWare178を入れてしまったので、SingleDisplayの状態だが軽くベンチ。
| VGA | GDI | Text | Square | Circle | BitBlt |
|---|---|---|---|---|---|
| GeForce 7600GT FW178 | 10012 | 1189 | 3666 | 1719 | 3438 |
| VGA | D2D | 10 | 100 | 500 | 1000 | 5000 | 10000 |
|---|---|---|---|---|---|---|---|
| GeForce 7600GT FW178 | 3485 | 465 | 320 | 130 | 75 | 17 | 9 |
・・・えっと、最新のForcewareって最新のチップに最適化されてるのね、と分かる数字ですなコレは。
まず、GDIに関しては思ったより落ちないな、というのが感想。Circleが半分以下に落っこちてたりするので、ドライバの挙動が違うのは間違いないが、それでも昨今ではバリュークラスのこのCPUでこの数字が出せるなら、ソレほど気にすることでもないかと。
それに、8500GTとほぼ同条件で比べてもBitBltに明確な速度差が出ているのは、やはりメモリ速度差が有意ということでしょう。
対して、とんでもないことになっているのがD2D。というか、絶対性能では勝ってる筈の8500GTと比べてここまでボロ負けするとはね・・・。いやはや、ハードウェアアクセラレーションは偉大だ。
Tags: 2DonGPU
