ギガビットイーサネットで950 Mbpsが上がるのに360 Mbpsしか下りないのはなぜですか？
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の結果
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つのスクリーンショットの図に注意してください。
データの送信から受信に切り替えたときに、右上の「1 Gbps」から「500 Mbps」に変化したことに気づきましたか。なぜそれをしたのですか？何らかの方法で他のネットワークポートをhalf 1 Gbpsと認識していますが、逆にfullと認識していますか？
ファイル転送テスト
さらに現実的なディスク間の読み取り値を取得するために、データファイルを使用してさらにテストを行いました。この目的で1 GBのファイルを作成しました。デフォルトの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ツールで得られた結果と一致しています。これが、リモートコンピュータにアップロードしたときの様子です。
それは103 MB/sを最大73％維持し、それから悪臭を放つと27.3 MB/sで82％になり、次にノッチが上がると93％で49.1 MB/sに達します。
次に、さらに面白い2つの「ジェットコースター」図を示します。
更新1-リンク速度
リモートコンピューターのWifiアダプターを無効にしてみました。 （Wifiアダプターはローカルコンピューターで既に無効になっています。）私はこれがTimtechのコメントでの意味だと思います。私は同じ考えを持っていました-有線と無線の両方のアダプターを同時に有効にすると、有線アダプターのスループットがWifiアダプターのレベルに制限されていた（互換性のために最も遅いアダプターに適応）。 Wifiアダプター（この場合はDWA-160ワイヤレスN）は通常、Vistaコンピューターによって "52 Mbps"-"104 Mbps"リンクとして検出されるためです。
次のスクリーンショットでは、リモートコンピューターがサーバーとして設定され、ローカルコンピューターがクライアントとして設定されています（192.168.100.152 <-192.168.100.151）。
しかし、リモートコンピューターのWifiアダプターを切断しても、有線接続のスループットが低下するのを助けませんでした。
それだけでなく！リモートコンピューターのWindowsタスクマネージャーでは、有線アダプター（LAN 1）のリンク速度は「1 Gbps」と表示されます。上記のスクリーンショットを参照すると、ローカルコンピューターで「500 Gbps」リンクとして検出されていることがわかります。したがって、同じ有線接続の場合、Windows Vistaでは1 Gbpsリンクと表示されますが、Windows 8.1 Proでは500 Gbpsリンクと表示されますが、どちらが正しいですか。
リモートコンピューターでクライアントとして、ローカルコンピューターでサーバー（192.168.100.152-> 192.168.100.151）を設定すると、次のようになります。
ここでわかるように、1 Gbpsリンクの約95％が使用されています。これは、950 Mbpsに相当します。それはまさに私が上記のテストで得たものです。しかし、逆に言うと、まったく別の話になります。
Update 2-両面印刷とMDI-X
何人かが示唆したように、私は両面印刷の設定を見ました。以下のスクリーンショットからわかるように、ローカルコンピューターとリモートコンピューターの両方が自動ネゴシエーションモードに設定されています。
両方のコンピュータで「1.0 Gbps全二重」に変更してみました。次に、Iperfを使用して、以前と同じタイプのテストを行いました。ローカルコンピューターをサーバー、リモートコンピューターをクライアントとして使用すると、最大で950 Mbpsになります。ローカルコンピューターをクライアント、リモートコンピューターをサーバーとして使用すると、約360 Mbpsになります。
ここでは、これらのスクリーンショットを見てください。
ここに表示されているのは、2台のコンピューター間でアップロードとダウンロードを行うときの図です。高い方のグラフ（使用率95〜98％）はローカルからリモート（アップストリーム192.168.100.152-> 192.168.100.151）です。下のグラフ（使用率〜33％）はローカルから離れています（ダウンストリーム192.168.100.152 <-192.168.100.151）。
Auto MDI-Xの問題を排除するために、ケーブル（ローカルコンピューター）の一端にクロスオーバーアダプターの1つを取り付けました。
それは確かにケーブルをクロスケーブルにするでしょう。地獄、私はそれをネットワークテスターでテストしてもらいました！これは確かに交差しています（ピン1/3、2/6）！
これで、2台のコンピューター間に真のクロスオーバーケーブル接続ができ、手動で「1.0 Gbps全二重」を設定しました。しかし、私はまだ同じ問題を抱えています。これ以上のアイデア？ Vistaコンピュータのアップグレード（または8.1コンピュータの再インストール）に加えて？
Update 3-ソフトウェアまたはハードウェアの制限？
私の推測では、互いに互換性のない2つのオペレーティングシステムを使用しています。これらは両方ともWindowsシステムですが、すべてのWindowsシステムが同等になるわけではありません。両方でVistaを使用するか、両方で8.1 Proを使用して、どのようなスループットが得られるかを確認する必要があります。 それはアップグレードを購入することを意味します。くそーマイクロソフト。
ちなみにどちらのコンピューターもカスタムビルドされています。ここにいくつかの仕様があります。
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
Tonnyさんは、Vistaマシンが悪いRealtekチップを使っているかもしれないと示唆しました。そこで、私はこれらの仕様を掘り下げました。現在、VistaマシンはBリビジョン8111を使用していますが、ローカルマシンは同じチップのCリビジョンを使用しています。これはどういう意味ですか？どちらも、製造元によって1000 Mbit（上記を参照）として明確に指定されています。 8111Bがそれほどパフォーマンスが低い（360 Mbps）のでしょうか？
これらの特定のドライブは、107 MB /秒のバーストレートに達します。これは、ローカルコンピュータでのテストで見た数値とまったく同じです。しかし、おそらく55 MB /秒の持続的なシーケンシャルまたはランダムな読み取り/書き込みでさえ、360 Mbpsに変換されません。これにより、440 Mbps前後のどこかが得られ、360 Mbpsは得られません。したがって、特に両方が同じドライブモデルを使用しているので、それがボトルネックになるとは思いません。さらに、ファイルコピー操作は1つですが、Iperfはディスクをまったく使用せず、テストにRAMメモリのみを使用します。
更新4-TCPチェックサムオフロード
Tonnyが提案したように、TCPチェックサムオフロード（IPv4およびIPv6の場合）をオフに切り替えてみました。
また、両方のコンピューターで "Speed＆Duplex"をautoに戻しました。しかし、これは助けにはなりませんでした。それでも、1方向のスループットは低く、もう1方向のスループットは高くなっています。
Update 5-新しいドライバーバージョン
ローカルとリモートの両方で、ドライバーのバージョンをGigabyte WebサイトおよびRealtek Webサイトからダウンロードした最新バージョンに更新してみました。
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)
私はまだ一方向で同じだらしないスループットを得ました。
更新6-CPU使用率
CPU使用率を確認しました。これは問題にはなりません。これが私の発見です。
On local...
Download: 4 - 10 %
Upload: 4 - 10 %
Idle: 0 - 4 %
On remote...
Download: 24 - 38 %
Upload: 10 - 25 %
Idle: 1 - 6 %
ローカル（ダウンロード、アップロード、アイドル）...
リモート（ダウンロード、アップロード、アイドル）...
リモートはより多くのCPUパワーを使用しますが、これはより遅いCore 2 Duoを使用したものでもあります。しかし、私のテスト中は38％ポイントを超えることはありませんでした。ここで特に興味深いのは、アップロード（ローカル<-リモート）よりもダウンロード（ローカル->リモート）の方がはるかに多くのCPUパワーを使用することです。
したがって、950 Mbpsのスループットでは38％を使用し、360 Mbpsでは25％を使用します。また、コア使用率はバランスが取れておらず、一方のコアを他方より多く使用しています。これからどのような結論を出すべきかわかりません。ローカルコンピューターはコア使用率を表示しないため、比較できません。しかし、CPU使用率はローカルコンピューターでも（ダウンロード/アップロードで10％）です。
Update 7-新しいIntel Gigabitネットワークアダプター
内蔵のRealtek RTL8111Bの代わりとしてIntelからの新しいPCI-Express Gigabitネットワークアダプターをリモートコンピューターにインストールしました。これはアップロードが遅すぎると思われます。 Intelアダプターの製品番号はEXPI9301CTです。私が読んだレビューによると、このアダプターは非常に良いはずです。これをボトルネックの可能性として除外したいだけです。
Iperf for Windowsを使用していくつかのテストを実行しました。結果は次のとおりです。
ローカル（ダウンロード、アップロード）...
リモート（ダウンロード、アップロード）...
平均して、このアダプターは実際にはRealtekアダプターより少し遅いです。 Realtekよりもオーバーヘッドが小さく、その結果、より安定した連続スループットが得られると思います。しかし、このIntelアダプタを使用しても、一方向で360 Mbps、反対方向で950 Mbpsしか得られません。
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
ローカルからリモートへの最初のテスト実行で、なぜ113 MB/sでピークに達したのか、私にはわかりません。テストの実行中もその速度を維持し、グラフは113 MB /秒でほぼフラットでした。前と同じように、実行ごとに60秒の間隔を使用しました。ただし、次の実行では、104 MB /秒に低下しました。
これらの値からわかるように、このIntelアダプターでも、組み込みのRealtekアダプターと同じスループットが得られます。ですから、アダプタ自体とは何の関係もないと言っても安全だと思います。したがって、RTL8111Bが他のマザーボードにあるRTL8111Cよりも劣っている/少ないチップであると非難することができます。これは、ますますソフトウェア/ OS /構成の問題のように見えるか、または3つすべてを一度に見ています。
アップデート8-Ubuntu LINUXで素晴らしい結果が得られました
他のすべてのオプションを使い果たした後、Linuxでいくつかのテストを実行することを最終的に決定し、素晴らしい結果を得ました。ローカルマシンとリモートマシンの両方で、Ubuntu Linux 13.10 LiveシステムとLinux用Iperf（バージョン2.0.5-3）を使用しました。結果は次のとおりです。
=======================================================
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
ローカル（ダウンロード、アップロード、アイドル）...
ご覧のとおり、Ubuntuを使用すると、両方向で同じスループットが得られます。両方のマシンで同じOSを使用しているためでしょうか、それとも別のものですか？両方のマシンで同じWindowsバージョンをセットアップした場合、同じスループットが得られますか？少し古いWindowsバージョン、つまりVistaを一方のマシンで使用し、最新バージョンをもう一方のマシンで使用するとどうなるのか理解できません。Vistaは現在もサポートされているOSであり、Microsoftによってバックアップされています。 。 Windows XPは別の話です。
しかし、私は彼らがVistaを倒すためにできる限りのことをしていることを知っています。たとえば、最新のOffice 2013はWindows Vistaでは意図的にサポートされていません。 MicrosoftがVistaが起こらなかったことを願っていると私は確信している。彼らがWindows 8.0が起こらなかったことを望んでいるように。しかし、私は通常、それらと同じくらい永続的であり、絶対に必要になるまでWindowsインストールをアップグレードしません。
したがって、問題は、2つの異なるWindowsバージョンで両方向に同じスループットを取得する方法です。 Windows Vistaはギガビット速度に対応している必要があります。これは20年前のOSではなく、私たちが話しているWindows 95ではありません。 Vistaは最新のOSです。両方のマシンで同じWindowsバージョンを実行することはまだテストしていません。 TCP実装または2つのOSバージョン間で何か違いがある可能性があります。その場合、おそらくVistaマシンをアップグレードすることを強制されます。それかLinuxに切り替えます。私はより少ない料金でより多くの料金を支払う準備ができていません。なぜ両方向でギガビットのスループットを得るためだけにWindowsをアップグレードしなければならないのですか？...
更新9 ...
ケーブル
ケーブルを逆にしてみました。以前と同じ結果が得られました。また、新しいCat 6パッチケーブルを入手して、それを試しました。スループットテストの結果は同じでした。したがって、ケーブルはここでは問題になりません。終端処理済み/成形済みのパッチケーブルのみを使用しました。したがって、配線は正しいはずです。ただし、後で自分の設置ケーブルを終端する予定です。
FWおよびAV
ファイアウォール（FW）とアンチウイルス（AV）については、サードパーティのFWまたはAVソフトウェアは使用していません。 Windows FirewallとSecurity Essentialsしか持っていません。両方のマシンで両方とも無効にしています。スループットテストの結果は以前と同じでした。
LAN速度テスト
ローカルマシンにLAN Speed Test Lite 1.3をインストールしました。ローカルマシンのメモリとリモートマシンのディスクドライブの間でテストが実行されたと思います。よく分かりません。しかし、リモートマシンで共有パスを要求します。リモートでo $共有を使用しました。
Upload: 427 Mbps
Download: 420 Mbps
私はこれらの結果をあまり信用していません。グラフを見ると、テスト全体で非常に変動していることがわかります。このテストは「成功した」テストでした。つまり、最初に書き込み（アップロード）テストを行い、次に読み取り（ダウンロード）テストを行いました。当然、アップロード/ダウンロードの同時テストを行うと、全体的なスループットが低下します。しかし、私はそのようなテストには興味がありません。これまでのところ、私はWindows（ファイル共有/ smb）とIperfの両方のファイル転送テストで「連続」テストのみを行っています。
リモートでLSTサーバーと呼ばれるプログラムを使用する必要があり、このプログラムを使用するには登録が必要なため、LAN速度テストを使用したメモリー間のテストは行っていません。
更新10 ...
ディスクドライブテスト
Crystal Disk Mark 3.0.3を使用してディスクドライブをテストしました。結果は次のとおりです。
Local disk: 118 MB/s read, 113 MB/s write
Remote disk: 70 MB/s read, 69 MB/s write
これらは、5回の実行と1000 MBの負荷に基づく読み取りと書き込みの順次速度です。
これはローカルディスクです（ディスクマーク、読み取り、書き込み）...
そしてこれがリモートディスクです...
しかし、私はこれを取得しません...これらの結果は矛盾しているようです。
ローカルディスクは118 MB/sで読み取ることができるため、約100 MB/sのアップロードが報告されます。しかし、リモートディスクが69 MB /秒の書き込みしかできない場合、リモートディスクはそれを受信できません。しかし、いくつかの魔法のひねりによって、平均で100 MB/sを少し超えるアップロードしか得られません。
逆に移動する方が理にかなっています。リモートディスクが70 MB /秒で読み取ることができ、ローカルディスクが113 MB /秒で書き込むことができる場合、ダウンロードは70 MB /秒より速くてはいけません。平均で約40 MB /秒のダウンロードが得られます。それは理にかなっているようです。
だから私はこれらの結果から何も結論付けることができません。つまり、ローカルコンピュータのディスクドライブはほとんど使用されていません。これはOSを保持するディスクでもあり、そのシステムで唯一のパーティションです。リモートディスクはほぼいっぱいですが、複数のパーティションでパーティション化されています。ただし、OSでは使用しません。ここでは、ドライブ文字O:を選択しました。これは、これが最も空き容量の多いパーティションだからです。
（以前のテストでは、リモートマシンのOSを保持する完全に別のSeagateディスクドライブにあるドライブ文字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
実質的に変化はありませんでした。リブートせず、リブートは要求されませんでした。
QOSパケット
次に、リモートマシンの適切なアダプタ、次にローカルマシンのQOSパケットスケジューラを無効にしました。
Local to remote: 107 MB/s
Remote to local: 41.9 MB/s
ここでは大きな変化はありません。この場合も、再起動や再起動は要求されませんでした。
ジャンボパケット
次に、4 GBが両方のマシンでサポートされている最大のMTUサイズであるため、4 GB設定を使用してジャンボパケットを有効にしました。
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
そのため、アップロードはさらに速くなりましたが、再起動後でも、これらの変更を行う前よりもダウンロードが遅くなっています。どちらも少し上がると思っていました。これは何を意味するのでしょうか？
あなたの回答に基づいて：
@ewhacローカルマシンのTCPウィンドウサイズは、通常、リモートマシンのウィンドウサイズとは異なります。デフォルト値は、ローカル（win 8）では0.06 MB、リモート（Vista）では0.01 MBです。それらは同じ値でなければなりませんか？ MSSを推測する方法を教えてください。それは-mスイッチでしょうか（ "print maximum segment size"）？通常は設定しません。なぜしなければならないのですか？ –サミー11月30日21:39
TCPウィンドウサイズは、TCPスタックが停止してリモートマシンからの確認応答の受信を待機する前にワイヤーブラインドを噴出するデータの最大量、つまり、確認応答されていないトラフィックの最大量を表しますワイヤー上。 VistaマシンのTCPウィンドウがWindows Se7enマシンよりもはるかに小さいという事実は、ACKを停止して待機する前にパイプを十分に満たしていないという理論を裏付けています。
したがって、最初に試すのは、-w引数を使用してVistaマシンのTCPウィンドウサイズを大きくすることです。 0.01MBはやや役に立たない単位です。 16KiBだと思います。したがって、16KiBから始めてテストを実行します。
iperf -c -w 16K ...
ウィンドウサイズを2倍にしてテストを繰り返します。
iperf -c -w 32K ...
うまくいけば、速度の増加を観察する必要があります。速度の大幅な向上が見られなくなるまで、ウィンドウサイズを2倍にします。
前述のように、低遅延の高速リンクでスループットを高めるには、TCP iperfのウィンドウサイズを変更する必要があります。Windows（またはiPerf）のバージョンによって、デフォルトのウィンドウサイズが異なる場合があります。 "-w 256k"を試してみてください両方クライアントとサーバー。
チャートの矢印の方向を確認できますか？ iPerfでは、データがプッシュされますfromクライアントがサーバーにプッシュされます（私が通常考えることの反対）。
IPerfはハードドライブに触れないので、原因としてハードドライブを除外できます。
最新のNIC=ドライバーを実行していることは既に確認済みだと思います。速度/デュプレックスを手動で設定する必要はありません。ジャンボフレームでも同じです。最新のハードウェアの面倒。
Large Send Offload（LSO）とLarge Receive Offload（LRO）が両方のNICで有効になっていることを確認します。一部のNICドライバは異なる名前（またはこの動作を制御する複数のオプション）を使用している）ので、探し回る必要があるかもしれません。通常、デフォルトでは、すべてのドライバが有効になっています。
Iperfの仕組みについてもう少し読む必要があると思います。正しいtcpウィンドウサイズを設定しないと、結果が大きく異なります。私はその-wスイッチを信じています。このWebサイトは、最適なTCPウィンドウサイズの計算を支援します。これを計算するには、RTTと帯域幅を知る必要があります。 http://www.kehlet.cx/docs/tcpwin .php
また、「LANスピードテスト」ライトのような他のツールを試してみてください。これは、どちらかの端で共有間の転送を上下に行うだけです。その結果は、それを使って行われたテストで非常に近いです。また、ハードドライブの最大r/w速度を確認してください。
TCP IPスタックは、Windows 7以降のリリースで異なる方法で実装されています。私のTCP最適化を詳しく見ていきます。 、2つのボックスの間にそれほど多くはないかもしれませんが、それでもVistaボックスのいくつかの設定を調整する価値があります。
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補足カスタム300 10 ctcp無効50次に次のように入力します：netsh int tcp set補足カスタム
上記のコマンドの詳細については、次のように入力してください：netsh int set補足
現在使用しているcongestionproviderを確認するには、以下を使用します。netsh int tcp show補足
しかし、Win Server 2012のみがカスタムテンプレートを作成できますCTCPが問題になる可能性があります。
また、自動スケーリングも要因になる可能性があります。
おそらくアップグレード/ダウングレードが必要なドライバーを確認する価値があります。どれが最も効果的かを確認してください。
もう1つの考えは、HDDに書き込まれるパケットサイズです。512b〜64KにフォーマットされたHDDセクターのサイズは、キャッシュのボトルネックになる可能性があります。
ジャンボパケットの有効化を確認しましたか（これがNICに該当する場合）
MMCSSサービスを停止してみてください。はい、一時的に音声が失われますが、何かが音声をアクティブにしているために、ネットワークアクティビティが抑制され、ネットワークアクティビティが他のアクティビティに影響を与えていない可能性があります。
MMCSSとネットワークスロットリングに関する情報については、ここを参照してください。 http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx
これらの指示に従って微調整できます： http://support.Microsoft.com/kb/948066
この場合、スループットが低下する可能性があるため、それが原因であるとは思えませんが、Vistaでのスループットの問題で頭を壁に長時間ぶつけた後、これが原因であることがわかりました。 NetworkThrottlingIndexを70に設定し、最終的に期待したスループットを得ました。
Ubuntu LINUXで素晴らしい結果
これはかなりおなじみのように聞こえます... Windowsではiperfのパフォーマンスがどうしても悪くなりますが、同じハードウェアがLinuxでも正常に動作します。
この戦いを何度も繰り返した結果、Windowsの iperfは不安定です という結論に達しました。なぜだかわかりません...正直なところ、Linuxから常に正しい結果を得ることができるので、思いやりをやめました。
そのため、パフォーマンスがこのように低下している理由を知りたい場合は、アプリケーションよりも遠くを見ないでください。
あなたが試していないのは、Vistaで Remote Differential Compression を削除することです。
私の考えは、Vistaでの広範なCPU使用に動機付けられています。これは、Vistaネットワークドライバーがこれをネットワークカードにオフロードする方法を認識していない可能性がありますが、Windows 8の方がはるかに効率的です。
詳細については、次の記事を参照してください。
リモート差分圧縮を無効にすることで、Vistaのネットワークを介したファイルの低速コピーを防止します 。
ただし、簡単に言えば、Remote Differential Compressionコントロールパネル->プログラムと機能-> Windowsの機能のオン/オフを切り替えて、再起動します。
以前は、しばらくの間、まったく同じ問題で尾を追いかけていました。片方向の転送速度が遅い、私の場合はアウトバウンド（アップリンク）。
Realtek Gigabit 8111C内蔵LANカードを搭載したWindows 7 Pro、Celeron J1800。 QNAP 453aおよびMacBook Pro。
Iperf3で測定すると、Windows 7をクライアントとして設定すると、112 mbpsが得られました（CPU使用率が25〜30％）。また、サーバーとして設定した場合のCPU使用率は50〜100％で39〜41 Mbpsにすぎません。帯域幅テスト時にPCがフリーズするほど悪い。
通常のファイル転送は、ファイルをNASまたはMACにアップロードまたはダウンロードしていたかどうかに関係なく、最大45mbpsに制限されています。
毎秒35〜45メガバイトしか得られませんでした。かなりイライラ！
最終的には悪いlanカードドライバーになりました。私はドライバーの更新に夢中になっており、新しいドライバーが利用可能になったときにドライバーを常に更新していました。何を推測した後、いくつかの更新後、私のlanカードの速度が低下しました。
古いドライバを削除して、新しいドライバをインストールする、と言う人もいるかもしれません。単純な、ああ？試してみましたが、うまくいきませんでした。
これが私の解決策です：
製造元のWebサイトからOEMドライバーを使用して、ウィンドウを最初からインストールしました。同様に私は次のことをしました：
[デバイスマネージャー]、[Lanカード]、[詳細設定]、[フローコントロール以外のすべてを無効にする]の下。
Windowsの機能の下で、リモート差分圧縮を無効にします。
現在、平均速度は80〜100 Mbpsです。
質の悪い写真でごめんなさい。
