2台のデスクトップ・コンピュータがお互いに直接通信しています。両方ともギガビットイーサネット対応のネットワークアダプタを持っています。それは 1 Gbps または 1000 Mbps です。真新しい10メートルのCat6 UTPストレートケーブルで接続していますが、理論上の最大値にかなり近づいています。Windowsのタスクマネージャ（ネットワークタブ）は、一方の方向に844 – 946 Mbpsを示しています。しかし、他の方向では、それだけで約326 – 365 Mbpsを示しています
Local: 192.168.100.152
Remote: 192.168.100.151
ローカルコンピュータはWindows 8.1 Proを実行しており、Windows Vista Ultimateを実行しているもう一方のコンピュータにリモートで接続しています
Iperf results
Iperfを使ってテストしてみました。毎回60秒のテストを行いました。通信の方向ごとに10回テストを行いました。そして、平均値を得るためにテスト結果をこの表にまとめました
192.168.100.152 -> 192.168.100.151 106 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 107 MB/s
192.168.100.152 -> 192.168.100.151 104 MB/s
192.168.100.152 -> 192.168.100.151 101 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
192.168.100.152 -> 192.168.100.151 108 MB/s
----------------------------------------------------
Min: 101 MB/s Max: 108 MB/s Avg: 106.4 MB/s (851.2 Mbps)
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.0 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
192.168.100.152 <- 192.168.100.151 41.1 MB/s
-----------------------------------------------------
Min: 41.0 MB/s Max: 41.1 MB/s Avg: 41.07 MB/s (328.56 Mbps)
質問なんだけど、なんで他の方向に行くとこんなに遅くなるの？
Windowsのタスクマネージャー
これは、Iperfでテストを実行しているときに見たネットワーク図です
次の2つのスクリーンショットの図に注意してください!
データ送信からデータ受信に切り替えると、右上の「1Gbps」から「500Mbps」に変わっているのに気がつきましたか？なぜそうなったのでしょうか？片道では1Gbpsの半分になっているのに、もう一方のネットワークポートでは満杯になっているというのは、どういうわけか感知しているのでしょうか？
ファイル転送テスト
より現実的なディスク対ディスクの読み取り値を得るために、データファイルを使っていくつかのテストを行いました。この目的のために1GBのファイルを作成しました。Windowsのデフォルトのファイル共有機能のみを使用しました。ローカルコンピュータからリモートコンピュータのC$共有に接続し、ファイルをドラッグ＆ドロップ（ロープスキッピング）して、その都度ファイル名を変更しました。私は私の能力のベストを尽くしてすべての時間を計り、これが私が得たものです
192.168.100.152 -> 192.168.0.151 1073741824 Byte 25 s 40,96 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 20 s 51.2 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 16 s 64 MB/s
192.168.100.152 -> 192.168.0.151 1073741824 Byte 16 s 64 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 34 s 30.118 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
192.168.100.152 <- 192.168.0.151 1073741824 Byte 11 s 93.091 MB/s
Windowsのファイルコピー図で示されたスループットは、別の話をしています。ここでは、2 つのファイルを同じディスク上の 2 つの異なる場所に次々とダウンロードしています。最初のコピーは 107 MB/s で 41% まで持続し、2 番目のコピーは 98.9 MB/s で 87% まで持続しています
ということで、これはIperfツールで得た結果と一致しています。さて、リモートコンピュータにアップロードするとこんな感じになります
73%まで103MB/sを維持し、82%で27.3MB/sの悪臭を放ち、93%で49.1MB/sに達するまでノッチアップします ここでは、さらに2つの面白い「ジェットコースター」の図を見てみましょう 更新1 – リンク速度 リモートコンピュータのWifiアダプタを無効にしてみました。(ローカルコンピュータではすでにWifiアダプタは無効化されていました。)これがTimtechさんのコメントの意味だと思います。私も同じように考えていました – 有線アダプタと無線アダプタを同時に有効にすると、有線アダプタのスループットがWifiアダプタのレベルに制限されてしまう（互換性のために最も遅いアダプタに適応する）ということでした。なぜなら、Wifiアダプタ(この場合はDWA-160 Wireless N)は、通常、Vistaコンピュータでは「52Mbps」〜「104Mbps」のリンクとして検出されるからです 以下のスクリーンショットでは、リモートコンピュータをサーバとして設定し、ローカルコンピュータをクライアントとして設定しています(192.168.100.152 <- 192.168.100.151) しかし、リモートコンピュータのWifiアダプタを外しても、有線接続での低スループットはどうにもならなかった それだけではありません!リモートコンピュータのWindowsタスクマネージャでは、有線アダプタ(LAN 1)のリンク速度が「1Gbps」と表示されています。上のスクリーンショットを参照すると、ローカルコンピュータでは「500Gbps」のリンクとして検出されていることがわかります。つまり、同じ有線接続でも、Windows Vistaでは「1Gbps」と表示され、同時にWindows 8.1 Proでは「500Gbps」と表示されている……ということは、どちらが正しいのでしょうか？ リモートコンピュータをクライアントとして、ローカルコンピュータをサーバとして設定したときの様子は以下の通りです(192.168.100.152 -> 192.168.100.151) ここにあるように、1Gbpsのリンクの約95%が利用されています。つまり950Mbpsになります。これは、上のテストで得たものと全く同じです。しかし、その逆を行くと全く別の話になります アップデート2 – デュプレックスとMDI-X 何人かの方に提案されたように、私は二重設定を見てみました。以下のスクリーンショットを見ればわかるように、ローカルコンピュータとリモートコンピュータの両方がオートネゴシエーションモードに設定されていました 両方のパソコンで「1.0Gbps全二重」に変更してみました。その後、Iperf を使用して、以前と同じようなテストを行いました。ローカルコンピュータをサーバとして、リモートコンピュータをクライアントとして使用した場合、最大約950Mbpsを得ることができました。ローカルコンピュータをクライアントとして、リモートコンピュータをサーバとして使用した場合、約360Mbpsの速度が得られました ここでは、これらのスクリーンショットを見てみましょう ここに表示されているのは、2台のコンピュータ間でアップロードとダウンロードを行った場合の図です。上のグラフ(95〜98%の利用率)はローカルからリモート(アップストリーム 192.168.100.152 -> – 192.168.100.151)です。下のグラフ（〜33％の利用率）はリモートからローカル（ダウンストリーム 192.168.100.152 <- 192.168.100.151）です Auto MDI-X の問題を除外するために、ケーブルの片方の端（ローカルコンピュータ）にクロスオーバーアダプターを接続していました それは確かにケーブルをクロスオーバーケーブルにするだろう。ネットワークテスターでテストしてみましたが、確かにクロスしています。それは確かに今（ピン1/3, 2/6）クロスしています! そこで今、私は2台のコンピュータ間で真のクロスオーバーケーブル接続を行い、手動で “1.0Gbps全二重 “を設定しました。しかし、私はまだ同じ問題を抱えています。何か他のアイデアはありますか？Vistaコンピュータのアップグレード（または8.1コンピュータの再インストール）のほかに？ アップデート3 – ソフトウェアまたはハードウェアの制限？ 私の一番の推測は、お互いに互換性のない2つのオペレーティングシステムを持っているということです。両方とも Windows システムですが、すべての Windows システムが同じように作られているわけではありません。両方で Vista を使用してみるか、または両方で 8.1 Pro を使用してみて、どのようなスループットが得られるかを確認しなければなりません。 ちなみにどちらのパソコンもカスタムメイドです。スペックをご紹介します Tonny は Vista マシンが悪い Realtek チップを使っているのではないかと提案してくれました。そこで、私はこれらのスペックを調べてみました。Vistaのマシンは8111のBリビジョンを使用していますが、ローカルのマシンは同じチップのCリビジョンを使用しています。これは何か意味があるのでしょうか？どちらもメーカーによって1000Mbitと明記されています（上記参照）。8111Bはそれだけ（360Mbps）の性能を持っているということでしょうか？ これらの特定のドライブは、107 MB/秒のバーストレートに達します。これは、私がローカルコンピュータ上のテストで見た数字です。しかし、55MB/sの持続的なシーケンシャルまたはランダムな読み書きでさえ、360Mbpsにはなりません。これは私が取得している360 Mbpsではなく、440 Mbpsの周りのどこかを与えるはずです。両方とも同じドライブモデルを使用しているので、それがボトルネックになっているとは思えません。それに、ファイルのコピー操作は一つのことですが、Iperf はディスクを全く使っておらず、テストに RAM メモリだけを使っています アップデート 4 – TCP チェックサムのオフロード Tonnyさんの提案通り、TCPチェックサムのオフロードをオフにしてみました（IPv4とIPv6用） また、「スピード＆デュプレックス」を両方のコンピュータで自動に戻しました。しかし、これは役に立ちませんでした。私はまだ一方の方向のスループットが低く、他方の方向のスループットが高いままです アップデート5 – 新しいドライバのバージョン ローカル、リモートともにGigabyteのサイトとRealtekのサイトからダウンロードしたドライバのバージョンを最新版にアップデートしてみました 相変わらず一方向ではお粗末な処理能力を発揮していました アップデート6 – CPU使用率 CPUの使用率を調べてみました。これは問題ないはずです。以下、私の調べた結果です ローカル（ダウンロード、アップロード、アイドル） リモート（ダウンロード、アップロード、アイドル） リモートの方がはるかに多くのCPUパワーを使用していますが、これもまた遅いCore 2 Duoを搭載したものです。しかし、私のテストでは38%ポイントを超えることはありませんでした。ここで特に興味深いのは、アップロード時(ローカル<-リモート)よりもダウンロード時(ローカル>リモート)の方が、非常に多くのCPUパワーを使用しているということです そのため、950 Mbpsのスループットでは38%を使用し、360 Mbpsでは25%を使用しています。また、コアの使用率もバランスが取れておらず、一方のコアを他方のコアよりも多く使用しています。これでは、どのような結論を出せばいいのかわかりません。ローカルコンピュータにはコア利用率が表示されていないので比較できません。しかし、CPUの使用率はローカルコンピュータでも（ダウンロード/アップロードでは10％） アップデート7 – 新しいIntelギガビットネットワークアダプタ 私は今、アップロードが遅いと言われているリモートコンピュータに内蔵のRealtek RTL8111Bの交換用として、Intelの真新しいPCI-Expressギガビットネットワークアダプタをインストールしました。Intelの製品番号はEXPI9301CTです。このアダプタは、私が読んだレビューによると、非常に良いとされています。私はただ、これがボトルネックになる可能性があることを除外したいと思っています 今、Iperf for Windowsでテストをしてみました ローカル（ダウンロード、アップロード） リモート（ダウンロード、アップロード） 平均すると、このアダプタは実際にはRealtekのアダプタよりも少し遅いです。Realtek よりもオーバーヘッドが小さく、その結果、安定した連続スループットが得られていると思います。しかし、私はこのIntelのアダプタを使っても、一方向では360Mbps程度、他方向では950Mbps程度しか出ません なぜ最初のテスト実行で113MB/sでピークアップしたのか、ローカルからリモートまで、私にはさっぱりわかりません。それはテスト実行中ずっとその速度を維持し、グラフは113 MB/sでほぼフラットでした。前と同じように、私は各実行に60秒のインターバルを使用しました。しかし、次の実行では104 MB/sまで低下しました これらの値を見てもわかるように、このIntelアダプタを使っても、内蔵のRealtekアダプタを使った場合と同じスループットが得られています。ですから、アダプタ自体には何の関係もないと言っていいと思います。ということで、RTL8111Bが他のマザーボードにあったRTL8111Cよりも劣る/劣ったチップであることを責めるのはやめよう。これは、ソフトウェア/OS/設定の問題か、3つの問題が同時に発生しているように見えます アップデート8 – Ubuntu LINUXで素晴らしい結果が得られました 他のすべてのオプションを使い果たした後、私は最終的にLinuxでいくつかのテストを実行することにしました、と私は素晴らしい結果を得ました。私はUbuntu Linux 13.10 LiveシステムとIperf for Linux (バージョン2.0.5-3)をローカルとリモートの両方のマシンで使用しました。結果は以下の通りです ローカル（ダウンロード、アップロード、アイドル） あなたが見ることができるように私はUbuntuを使用しているときに両方の方向で同じスループットを取得します。両方のマシンで同じOSを使っているからなのか、それとも何か他に原因があるのでしょうか？私は両方のマシンで同じWindowsのバージョンを設定していた場合、私は同じスループットを得るだろうか？私は、私が一方のマシンと他の上に最新のバージョンで、わずかに時代遅れのWindowsのバージョン、すなわちVistaを使用している場合、それが問題になる理由が理解できません？私が意味するのは、Vistaはまだ最新でサポートされているOSであり、Microsoftによってバックアップされているということです。Windows XPは別の話です しかし、彼らはVistaを殺すために全力を尽くしていることを知っている。例えば、最新のOffice 2013は意図的にWindows Vistaではサポートされていない。マイクロソフトは、Vistaが起こらなかったことを願っているのだろう。Windows 8.0が起こらなかったことを願うのと同じように。しかし、私も普段は彼らと同じようにしつこく、絶対に必要になるまではWindowsのインストールをアップグレードしない そこで問題なのは、2つの異なるWindowsのバージョンで、どのようにして双方向で同じスループットを得るかということです。Windows Vistaはギガビットの速度が可能なはずだ – 20年前のOSとかではないし、我々が話しているWindows 95でもない。Vistaは最新のOSです。私はまだ両方のマシンで同じWindowsのバージョンを実行するテストをしていません。もしかしたらTCPの実装の違いか何かがあるのかもしれません。もしそうだとしたら、Vistaのマシンをアップグレードせざるを得ないだろう。それかLinuxに乗り換えるかのどちらかだ。私は、安いものに多くを支払う準備ができていません。ギガビットのスループットを双方向で得るためだけに、なぜWindowsをアップグレードしなければならないのか Update 9… Cable ケーブルを逆にしてみました。前と同じ結果になりました。また、新しいCat 6パッチケーブルを手に入れて、そちらも試してみました。スループットテストの結果は同じでした。つまり、ここではケーブルは問題ではないということです。私が使用したのは、事前に終端処理された/成形されたパッチケーブルだけです。だから配線は正しいはずだ。しかし、私は後で自分のインストールケーブルを終端する予定です ＦＷとＡＶ ファイアウォール(FW)とアンチウィルス(AV)に関しては、私はサードパーティ製のFWやAVソフトは一切使っていません。Windowsファイアウォールとセキュリティエッセンシャルズしか持っていません。両方のマシンで無効にしています。スループットテストの結果は以前と同じでした LANスピードテスト ローカルマシンにLAN Speed Test Lite 1.3をインストールしました。ローカルマシンのメモリとリモートマシンのディスクドライブの間でテストが行われていると思います。よくわかりません。しかし、リモートマシン上の共有パスを要求してきます。リモートでo$の共有を使ってみました 私はこの結果をあまり信用していません。グラフを見てみると、テスト中は非常にばらつきがあることがわかります。このテストは “連続 “テストで、つまり、最初に書き込み(アップロード)テストを行い、次に読み込み(ダウンロード)テストを行いました。明らかに、同時アップロード/ダウンロードテストを行う場合、全体的なスループットは低くなります。しかし、私はそのようなテストには興味がありません。これまでのところ、私はWindows（ファイル共有/smb）とIperfでのファイル転送テストの両方で「連続した」テストだけを行ってきました LAN Speed Testでのメモリ対メモリテストは、リモートでLST Serverというプログラムを使う必要があり、このプログラムを使うには登録が必要なので、私はやっていません Update 10… ディスクドライブのテスト Crystal Disk Mark 3.0.3を使ってディスクドライブのテストをしてみました。その結果をご紹介します これらは、5回の実行と1000MBの負荷に基づくシーケンシャルな読み書き速度です これがローカルディスク（ディスクマーク、リード、ライト） そしてこれがリモートディスク しかし、この結果は矛盾しているように思えてなりません Okey, ローカルディスクは118 MB/sで読み込めるので、報告されているアップロードは約100 MB/sになります。しかし、リモートディスクは69 MB/秒の書き込みしかできない場合、それを受信することはできません。しかし、いくつかの魔法のねじれによって、私はまだ平均で100 MB/秒のアップロードを少し以上取得します 逆の方法をとる方が理にかなっています。リモートディスクが 70 MB/s で読み込めて、ローカルディスクが 113 MB/s で書き込めるのであれば、ダウンロードは 70 MB/s より速くはないはずです。私は平均して約 40 MB/s のダウンロードを得ています。これは合理的に見えるでしょう なので、この結果からは何の結論も出せません。つまり、ローカルコンピュータのディスクドライブはほとんど使われていないということです。OSを格納しているディスクでもあり、そのシステム上の唯一のパーティションでもある。一方、リモートのディスクはほぼ満杯で、それもいくつかのパーティションで仕切られています。しかし、OSには使われていません。ここでは、一番空き容量があるパーティションなので、ドライブレター (以前のテストでは、リモート・マシン上のOSを保持する全く別のシーゲイト・ディスク・ドライブ上のドライブ文字 Write caching ディスクライトキャッシングを有効にすると、このような結果が得られました そして、リモートとローカルドライブ上のすべてのドライブのライトキャッシングを無効にしました 変更を有効にするために再起動を要求されなかったので、再起動はしませんでした。すると、以下のような結果が出ました 実質的に全く変化がありませんでした。再起動も要求されませんでした QOS packet その後、リモートマシン上の適切なアダプタのQOS Packet Schedulerを無効にし、ローカルマシン上のQOS Packet Schedulerを無効にしました ここでは目立った変化はありません。繰り返しになりますが、再起動は要求されず、再起動もできませんでした Jumbo packets その後、私はジャンボパケットを有効にするために進みましたが、4KBは両方のマシンでサポートされている最大のMTUサイズなので、私は4GBの設定を使用しました さて、ここで、アップロード（ローカルからリモートへのアップロード）には影響はなかったが、ダウンロードのスループットが大幅に低下した。再起動は要求されませんでしたが、念のため、とにかく両方のマシンを再起動することにしました。その後、再度同じテストを行ったところ、このような結果が得られました そのため、アップロードはさらに速くなりましたが、ダウンロードは再起動後も、これらの変更を行う前よりも遅くなっています。両方とも少しは上がると思っていたのですが。これは何を意味するのでしょうか？ 47 community wiki None あなたの回答をもとに @ewhac ローカルマシンの TCP ウィンドウサイズは、通常、リモートマシンのウィンドウサイズとは異なります。デフォルト値はローカルでは 0.06 MB (win 8)、リモートでは 0.01 MB (vista) です。これらは同じ値でなければなりませんか？どのようにして MSS を推測させるのでしょうか？それは -m スイッチ (“print maximum segment size”) でしょうか？普段は何も設定していません。なぜ私が設定しなければならないのでしょうか？- サミー 11月30日 21:39 TCP ウィンドウのサイズは、TCP スタックが停止してリモートマシンからの確認応答を受け取るのを待つ前に、ワイヤブラインドから吹き出すデータの最大量を表しています。Vista マシンの TCP ウィンドウが Windows Se7en マシンよりもはるかに小さいという事実は、停止して ACK を待つ前にパイプを十分に充填していないという理論を支持しています したがって、私が最初に試したいのは、 ウィンドウサイズを2倍にしてテストを繰り返します うまくいけば、速度の増加が見られるはずです。速度の大幅な増加が見られなくなるまで、ウィンドウサイズを2倍にし続けます 6 community wiki 2013-12-04 前述のように、低遅延の高速リンクでより高いスループットを得るためには、iperf の TCP ウィンドウサイズを変更する必要があります。異なるバージョンの Windows (または iPerf) では、デフォルトのウィンドウサイズが異なる場合があります。クライアントとサーバの両方で “-w 256k” を試してみてください チャートの矢印の方向を確認できますか？iPerfでは、データはクライアントからサーバーにプッシュされます iPerfはハードディスクを触っていないので、ハードディスクが原因ではないと断定できます 最新のNICドライバを実行しているかどうかは既に確認済みだと思いますが、手動で速度/デュプレックスを設定する必要はありません。手動で速度/デュプレックスを設定する必要はありません。ジャンボフレームについても同様で、最新のハードウェアでは手間をかける価値はありません 両方の NIC で Large Send Offload (LSO) と Large Receive Offload (LRO) が有効になっていることを確認してください。NIC ドライバによっては、異なる名前（またはこの動作を制御する複数のオプション）を使用しているものがあるので、探し回る必要があるかもしれません。通常、デフォルトではこれらをすべて有効にします 4 community wiki 2013-12-09 iperfがどのように動作するかについてもう少し読む必要があると思います。正しいTCPウィンドウサイズを設定しなければ、結果は大きく変わるでしょう。私は -w スイッチだと思っています。このウェブサイトは最適なTCPウィンドウサイズを計算するのに役立ちます。あなたはそれを計算するためにRTTとバンドウィズを知っている必要があります。http://www.kehlet.cx/docs/tcpwin.php また、”LAN Speed test” lite のような他のツールも試してみてください。その結果は、それを使って行われたテストの中でかなり近いです。また、あなたのハードドライブの最大R/W速度が何であるかを確認してください 3 community wiki 2013-11-13 あなたの助けになるかもしれないいくつかのポイントをご紹介します。TCP IPスタックは、Windows 7以降のリリースでは異なる方法で実装されています。私は、私のTCPの最適化をよく見てみることにしました netsh int tcp set global congestionprovider=ctcp の使用は減価償却されました。congestionprovider を設定または変更するには、次のコマンドを使用する必要があります 記事はこちらからお読みください。http://forums.speedguide.net/showthread.php?280646-When-will-TCP-Optimizer-support-Windows-8-amp-Windows-Server-2012 netsh int tcp set supplemental custom 300 10 ctcp disabled 50 Then type: netsh int tcp set supplemental custom 上記のコマンドの詳細については、単に次のように入力してください: netsh int set supplemental 現在使用している congestionprovider を確認するには、次のようにします: netsh int tcp show supplemental しかし、唯一のWin Server 2012はカスタムテンプレートを作成することができますCTCPは多分問題です また、オートスケーリングも要因の一つかもしれません 多分あなたのドライバを見てみる価値があるかもしれないアップグレード/ダウングレードの必要性があります もう一つ考えられるのは、パケットサイズがHDDに書き込まれていることです。512b ~ 64KにフォーマットされたHDDのセクタのサイズは、キャッシュのボトルネックになっている可能性があります。GBit 速度を使用するときに検討する価値がある – または代わりに SSD ディスクでテストしてください! ジャンボパケットを有効にしてみたことはありますか？ 3 community wiki 2013-11-28 Ubuntu LINUXで素晴らしい結果が得られました Windowsでは 何度も何度もこの戦いを戦った結果、私はWindowsの そのため、なぜそのような悪いパフォーマンスを得ているのかを知りたいのであれば、アプリケーション以外のところに目を向けてはいけません 2 community wiki 2017-04-13 試してみてください。はい、あなたのオーディオを一時的に失うことになりますが、それは何かがそれを活性化している可能性があります、ネットワークの活動が他の活動をかき消すことはありませんようにスロットル化されたネットワークの活動を引き起こしています MMCSS とネットワークスロットルについての情報はこちらを参照してください。http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx こちらの指示通りにいじることができます。http://support.microsoft.com/kb/948066 しかし、Vista での自分のスループットの問題で長い間壁に頭をぶつけてきた後、これが原因であることを発見しました。NetworkThrottlingIndex を 70 に設定して、ようやく期待通りのスループットを得ることができました 2 community wiki 2013-12-08 試していないこととしては、Vista上のRemote Differential Compressionを削除することです 私の考えは、VistaでのCPU使用量が多いことに動機付けられています。これは、Vistaのネットワークドライバがこれをネットワークカードにオフロードする方法を知らないのに対し、Windows 8はこれをはるかに効率的に行っているからかもしれません 詳細については、記事を参照してください。 Vistaでリモート差分圧縮を無効にすることでネットワーク上でのファイルコピーが遅くなるのを防ぐ 2 community wiki 2013-12-08 以前の私はしばらくの間、全く同じ問題で私の尾を追いかけていました一方向の転送速度が遅い、私の場合はアウトバウンド（アップリンク） Windows 7 Pro、Celeron J1800にRealtek Gigabit 8111C内蔵LANカード。QNAP 453aともう片方のMacBook Pro Iperf3を使って測定したところ、Windows 7をクライアントとして設定した場合（CPU使用率は25～30％）、112 mbpsを得ていました。サーバーとして設定した場合は、CPU使用率が50～100%の間で、39～41Mbpsしか出ませんでした。帯域テスト時にはPCがフリーズするほどでした 通常のファイル転送は、NASやMACにファイルをアップロードしたりダウンロードしたりしていても、最大45mbpsに制限されていました 1秒間に35～45メガバイト以上のデータを取得していました。かなりイライラする！ 結局、悪いランカードドライバーになってしまった。私はドライバのアップデートに夢中で、新しいドライバが利用できるようになったら常にアップデートしていました。何だと思いますか、何回かのアップデートの後、私のlanカードは遅くなりました 古いドライバを削除して新しいドライバをインストールすればいいと言う人もいるでしょう。簡単だろ？私は試してみました、それは私のために動作しませんでした これが私の解決策です メーカーサイトの純正ドライバーでwindowsを一からインストール。同様に私は以下のことをしました デバイスマネージャ/Lanカード/詳細設定/フローコントロール以外はすべて無効にしてください Windowsの機能]で、[リモート差分圧縮を無効にする]を選択します 現在の平均速度は80～100Mbpsです 画質の悪い写真で申し訳ありません 0 community wiki 2017-04-28 YoutubeのLinus Tech TipsのLinusさんも同じ問題を抱えていたようで、申し訳ないのですが解決策を忘れてしまいました。これは最近の（2016年4月20日現在）のビデオで、私は間違っているかもしれませんが、私はそれがプロセッサ上の単一のスレッドが制限要因である場合であったことに終わったと思いますので、あなたが古いハードウェアを持っており、あなたが1Gbpsをヒットしようとしている場合、それは実際に問題となっているCPUであり、それはほとんどのオンボードNICは、これらの日を行うCPUに仕事の大部分をオフロードしている場合。私は間違っているかもしれませんが、それは彼の最近のビデオです、私は非常に彼のストリームをチェックすることをお勧めします。参考までに、私はギガビットインターネット接続で同じ問題に遭遇しています -2 community wiki 2016-04-21
それはアップグレードを買うことを意味します。くそったれ Microsoft.Local
-----
Gigabyte GA-EP45-UD3R
Intel Core 2 Quad Q9650
Intel P45
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Realtek 8111C chips (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows 8.1 Pro 64-bit
Remote
------
Gigabyte GA-X38-DQ6
Intel Core 2 Duo E4500
Intel X38
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Dual Realtek 8111B chip (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows Vista Ultimate 64-bit
Update path...
On local (RTL8111C):
8.1.510.2013 (2013-05-10, Microsoft)
8.20.815.2013 (2013-08-15, Realtek)
On remote (RTL8111B):
6.241.623.2010 (2010-06-23, Realtek)
6.250.908.2011 (2011-09-08, Realtek)
6.252.1109.2012 (2012-11-09, Realtek)
On local...
Download: 4 - 10 %
Upload: 4 - 10 %
Idle: 0 - 4 %
On remote...
Download: 24 - 38 %
Upload: 10 - 25 %
Idle: 1 - 6 %
local: 192.168.100.152 (win 8, realtek 8111c)
remote: 192.168.100.154 (vista, intel desktop ct)
192.168.100.152 -> 192.168.100.154 113 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 103 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 102 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
192.168.100.152 -> 192.168.100.154 101 MB/s
192.168.100.152 -> 192.168.100.154 102 MB/s
192.168.100.152 -> 192.168.100.154 101 MB/s
192.168.100.152 -> 192.168.100.154 104 MB/s
----------------------------------------------
Max: 113 MB/s Min: 101 MB/s Avg: 103.8 MB/s
192.168.100.152 <- 192.168.100.154 42.2 MB/s
192.168.100.152 <- 192.168.100.154 41.2 MB/s
192.168.100.152 <- 192.168.100.154 41.1 MB/s
192.168.100.152 <- 192.168.100.154 43.0 MB/s
192.168.100.152 <- 192.168.100.154 42.3 MB/s
192.168.100.152 <- 192.168.100.154 42.3 MB/s
192.168.100.152 <- 192.168.100.154 40.2 MB/s
192.168.100.152 <- 192.168.100.154 40.9 MB/s
192.168.100.152 <- 192.168.100.154 41.3 MB/s
192.168.100.152 <- 192.168.100.154 42.0 MB/s
-----------------------------------------------
Max: 43.0 MB/s Min: 40.2 MB/s Avg: 41.65 MB/s
=======================================================
REALTEK 8111C <-> REALTEK 8111B | IPERF ON UBUNTU LINUX
=======================================================
local: 192.168.100.152
remote: 192.168.100.151
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
192.168.100.152 -> 192.168.100.151 112 MB/s
----------------------------------------------
Max: 112 MB/s Min: 112 MB/s Avg: 112 MB/s
192.168.100.152 <- 192.168.100.151 110 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 110 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
192.168.100.152 <- 192.168.100.151 111 MB/s
----------------------------------------------
Max: 111 MB/s Min: 110 MB/s Avg: 110.8 MB/s
Upload: 427 Mbps
Download: 420 Mbps
Local disk: 118 MB/s read, 113 MB/s write
Remote disk: 70 MB/s read, 69 MB/s write
O:を選んでテストしてみましたC:を使用したことに注意してください。そのため、これらの測定値は比較できません)Local to remote: 106 MB/s
Remote to local: 42.2 MB/s
Local to remote: 106 MB/s
Remote to local: 42.1 MB/s
Local to remote: 107 MB/s
Remote to local: 41.9 MB/s
Local to remote: 105 MB/s
Remote to local: 33.3 MB/s
Local to remote: 117 MB/s
Remote to local: 33.2 MB/s
-w引数を使ってVistaマシンのTCPウィンドウのサイズを大きくすることです。0.01MBというのはやや参考にならない単位で、16KiBだと思います。そこで、16KiBから始めて、テストを実行してみてくださいiperf -c -w 16K ...
iperf -c -w 32K ...
iperfのパフォーマンスが不可解に悪いのですが、Linuxでは同じハードウェアでも問題なく動作しますiperfは欠陥があるという結論に達しました。なぜかはわかりません…正直なところ、linuxではいつでもまともな結果が得られることがわかっているので、気にするのをやめました
