Yukonって根本的に遅い？

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

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

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

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

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

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

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

　◇

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

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

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

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

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

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

　◇

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

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

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

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