原因不明の遅いギガビットネットワーク速度

Question

更新

わかりました、以下の答えを試しましたが、何も変わっていません。ラップトップのチップセットをNVIDIA nForce 520と識別しました。nForce520用の最新のVista x64ドライバーをダウンロードしました（NVIDIAには、Win 7用のそのチップセット用のドライバーがまだありません）。含まれているファイアウォールソフトウェアをインストールしようとしました（多分それは干渉していると思います-干渉していません）。ネットワークフィルタードライバーが問題を引き起こしている可能性があると考えて、ウイルス対策ソフトウェアを完全にアンインストールしました（私はアバストを使用しています！）。

私は自分のラップトップを兄弟の家に持ち帰り、彼の100Mビットのネットワークを介して10〜12 MB/sでファイルをコピーできたので、それはハードウェアではないと思います。

Iperfを実行して、いくつかの驚くべき結果が得られました。
ラップトップからサーバーに送信するiperf（アップロード）

> iperf -c naru ------------------------------------------------------------ Client connecting to naru, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [328] local 192.168.7.100 port 8549 connected with 192.168.7.6 port 5001 [ ID] Interval Transfer Bandwidth [328] 0.0-10.0 sec 162 MBytes 136 Mbits/sec > iperf -c naru -w 64k ------------------------------------------------------------ Client connecting to naru, TCP port 5001 TCP window size: 64.0 KByte ------------------------------------------------------------ [328] local 192.168.7.100 port 8550 connected with 192.168.7.6 port 5001 [ ID] Interval Transfer Bandwidth [328] 0.0-10.0 sec 1.06 GBytes 909 Mbits/sec

サーバーからラップトップに送信するiperf（ダウンロード）

> iperf -c miyuki ------------------------------------------------------------ Client connecting to miyuki, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [256] local 192.168.7.6 port 51871 connected with 192.168.7.100 port 5001 [ ID] Interval Transfer Bandwidth [256] 0.0-10.1 sec 25.2 MBytes 20.8 Mbits/sec > iperf -c miyuki -w 64k ------------------------------------------------------------ Client connecting to miyuki, TCP port 5001 TCP window size: 64.0 KByte ------------------------------------------------------------ [256] local 192.168.7.6 port 51872 connected with 192.168.7.100 port 5001 [ ID] Interval Transfer Bandwidth [256] 0.0-10.0 sec 21.1 MBytes 17.6 Mbits/sec

比較のために、HTPCとサーバー間のiperf番号を示します

Server: Naru, Host: CC (CC sends to Naru) iperf -c naru: 0.0-10.0 sec 363 MBytes 305 Mbits/sec iperf -c naru -w 64k: 0.0-10.0 sec 1.06 GBytes 912 Mbits/sec Server: CC, Host: Naru (Naru sends to CC) iperf -c cc: 0.0-10.0 sec 322 MBytes 270 Mbits/sec iperf -c cc -w 64k: 0.0-10.0 sec 1020 MBytes 855 Mbits/sec

Wiresharkを使用してサーバーからラップトップへの転送を監視すると、次のエントリが大量に発生します。

(:51aa is the server, :37a1 is the laptop) No. Time Source Destination Proto Info 37785 27.286240 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#13] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40517974 37786 27.286258 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#14] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40519414 37787 27.286277 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#15] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40520854 37788 27.286295 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#16] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40522294 37789 27.286313 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#17] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40523734 37790 27.286332 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#18] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40525174 37791 27.286351 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#19] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40526614 37792 27.286370 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Previous segment lost] [TCP segment of a reassembled PDU] 37793 27.286372 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP segment of a reassembled PDU] 37794 27.286375 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Fast Retransmission] [TCP segment of a reassembled PDU] 37795 27.286377 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Out-Of-Order] [TCP segment of a reassembled PDU] 37796 27.286379 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Out-Of-Order] [TCP segment of a reassembled PDU] 37797 27.286382 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1 TCP [TCP Out-Of-Order] [TCP segment of a reassembled PDU] 37798 27.286413 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#20] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40529494 SLE=40499254 SRE=40526614 37799 27.286432 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa TCP [TCP Dup ACK 37753#21] 8360 > Microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40530934 SLE=40499254 SRE=40526614

この時点で、私は次に何をしようとするかについて完全かつ完全に迷っています。

元の質問

バックグラウンド

新しくインストールしたWindows 7ラップトップで問題が発生しています。この問題は、Windows 7 RC版をインストールした後に最初に発生しました。このラップトップにWindows VistaとWindows 7 Beta 1がインストールされている場合、ジャンボフレームを9KB/9014の範囲に設定して、ギガビット速度で転送することができました。ラップトップ間の2つのスイッチは、ジャンボフレームもサポートします。

サーバーからラップトップにファイルをコピーすると、カタツムリのペース（通常は1 MB /秒未満）で実行されますが、同じスイッチを通過する他のデバイスはより高速（45〜55 MB /秒）で転送できます。ラップトップからサーバーネットへのコピーの方が高速ですが、そのようなものはありません。

画像

ラップトップからコピーを開始

サーバー->ラップトップ

_{（ソース： gibixonline.com ）}
ラップトップ->サーバー

サーバーから開始されたコピー

サーバー->ラップトップ

_{（ソース： gibixonline.com ）}
予期せずサーバーにファイルをラップトップからそれ自体にコピーさせると、予想通りの速度になります。（ラップトップ->サーバー）

_{（ソース： gibixonline.com ）}

以前に、同じスイッチ上の他のマシンにはこの問題はないと述べました。これはHDTVで表示されるため、高DPIがオンになっています。
サーバー-> HTPC

_{（ソース： gibixonline.com ）}

当然テストとして、ラップトップとHTPCの間の速度を確認することにしました。残念ながら、彼らはまさに私が期待したものでした。
HTPC->ラップトップ

_{（ソース： gibixonline.com ）}

最終メモ

私は思いつく限りのことを試しました。この時点ではジャンボフレームもオフになっているため、何の影響もないようです。使用しているケーブルを変更するために、アンチウイルス保護をオフにしてみました。現在使用中のケーブルはすべて私が作成したCAT-5eです。 HTPCからケーブルを取り出してラップトップに差し込み、ケーブル配線に問題がないか確認しました。問題の2つのスイッチは、D-Link DGS-1216Tと、ジャンボフレームをサポートする「ダム」スイッチであるD-Link DGS-2208です。

Tim Kennedy · Answer

Windowの自動調整機能を無効にしてみてください。

CMDウィンドウで：

netsh interface tcp set global autotuning=disabled

テストを再実行し、パフォーマンスの向上に気づいたかどうかを確認します。私はこれを自宅でWindows 7を実行しているいくつかのラップトップで実行する必要がありました。

状況が悪化したり、改善が見られない場合は、次の方法で自動チューニングを再度有効にできます。

netsh interface tcp set global autotuning=normal

Matt · Answer

ラップトップに問題がないかどうかを確認するには、ubuntu live cdを実行し、ramperにiperfをインストールして、テストを実行します。

これは、少なくともネットワーク側をテストする必要があります。

JJ01 · Answer

これはWindows 7の大きな問題のようです。この問題についていくつかのゲーマーが不満を述べています。

コマンドプロンプト（通常は[すべてのプログラム]-> [アクセサリ]-> [コマンドプロンプト]）から「regedit」を実行します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfacesに移動します
影響を受けるネットワークインターフェイス（通常、LAN IPアドレスは192.168または10.0で始まる）に一致するIPAddressエントリを持つものが見つかるまで、インターフェイスの下の項目を参照します。 IPアドレスがDHCPサーバーによって自動的に割り当てられる場合は、IPAddressではなく、一致するDhcpIPAddressを探す必要があることに注意してください。
インターフェイスを右クリックして[新規]> [DWORD（32ビット）値]を選択し、「TcpAckFrequency」という名前を付けます。
新しいTcpAckFrequency値を右クリックして[変更]を選択し、「1」と入力します（16進数のラジオボタンを選択する必要があります）
インターフェイスを右クリックして[新規]> [DWORD（32ビット）値]を選択し、「TCPNoDelay」という名前を付けます（TCPは今回はすべて大文字です-これは意図的なものです）
新しいTCPNoDelay値を右クリックして[変更]を選択し、「1」と入力します（16進数のラジオボタンを選択する必要があります）
TcpAckFrequencyとTCPNoDelayの両方が、タイプREG_DWORDと値0x00000001でアダプターのプロパティリストに表示されることを確認します
Regeditを終了して再起動します（変更を有効にするには再起動が必要です！）
1. ゲームをプレイして、新しい低pingをお楽しみください

これにより、ほとんどのゲームで私のpingが200〜300ミリ秒から50〜60ミリ秒に減少しました。これは、ゲームのサーバーへのトレーサーを介して見た場合の待ち時間と一致します。

から取られて、Windows 7またはVistaのゲームネットワークの待ち時間を減らします

Ben Campbell · Answer

他のAV製品でこれに出会ったことがあります。私の問題はSMBでした。「無効」でもAV製品が干渉しました。お使いのWiresharkで同様の結果が表示されました。ここに、根本的な原因に到達するために確認した多くのサイトの1つがあります。： Symantec SMB issue and another： SMB2 fail with NTP

さらに、SMB内の設定のすべてまたは一部を無効化/変更してみてください。 OSでv2を無効にすることも検討します。この記事をチェックしてください SMB Win Vista内の問題とこのMicrosoftへのリンクについて説明しています SMB = reg設定。

あなたがアバストについて言及したのは知っていますが、同じようなワイヤーシャークの結果を見たのはかなり偶然です。私の場合、ファイル転送以外はすべて正常に機能しているように見えました。

Dom · Answer

パケット署名を使用すると、クライアントがWindowsサーバーと通信するときに問題が発生しました。速度は低下しませんでしたが、接続ドロップアウトは非常に一般的でした。

私の問題を解決した解決策についてはここを読んでください。

また、TCP Chimney関数を1つずつオフにして、それらの1つが正しく機能していないかどうかを確認するための提案はありません。

The_aLiEn · Answer

O.s.のようですディスクに書き込む前にパケットをチェックしています。私はすべての遅い転送がラップトップに書き込もうとするものであることを観察しました...私は提案します

ラップトップhddのパーティションのブロックサイズをチェックします（ブロックサイズが小さいと、単一の大きなファイルを転送しようとするときに、空き領域のシーク時間が悪くなる可能性があります）。
着信パケットのディスク書き込みをチェックするファイアウォールポリシーをチェックする
ファイルアクティビティモニターをチェックします（これはアンチウイルスをアンインストールするため、心配する必要はありません）（avastはファイルのライブチェックを行い、ネットワーク転送を少し遅くします。
ターゲットパーティションの最適化（ここでも空き領域の検索について）

他の人が提案され、助けになっていないようです：

自動調整
二重レベル
ケーブル...

最後の提案は、nicの高度なプロパティでバッテリーモードリンクの検出を確認できますか？それはラップトップであり、省電力プロパティに問題がある可能性があります...バッテリーモードのリンク検出で「省エネルギーなし」を、バッテリーの速度設定で「フル」を試してください。

デスクトップPCでwin7を使用していますが、それらのオプションはNICの高度なプロパティに含まれていません。私がこの問題を経験したことがない限り、nicのオプションとして「Flow Control」の値を「TX and RX Enabled」にチェックすることもできます。ジャンボが無効になっていて、速度とデュプレックスも私の設定で自動です...

他の解決策は思いつきません...これが役に立てば幸い...

Gi Cakov · Answer

以前は、しばらくの間、まったく同じ問題で尾を追いかけていました。片方向の転送速度が遅い、私の場合はアウトバウンド（アップリンク）。

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です。

Chris Yunker · Answer

ドロップされたパケットを確認します。 Windowsでこれを行う方法はわかりませんが、Linuxマシンを使用している場合は、そこで確認できます。

私はギガビットスイッチで同様の経験をしましたが、ギガビットモードが壊れ、パケットがドロップされました。このモードで2台のマシンを接続しているときにのみ問題が発生しました。 100Kモードでは、すべてが正常でした。それは私が知るのに数日かかった厄介な問題でした。私はD-Linkだったのかもしれません。スイッチのモデルについてググる。私はそうしました、そして、他の人が私と同じ問題を抱えているのを見つけました。

Mark · Answer

あなたはアップデートでPCを打ち負かし、失敗することなくオフサイトでテストしました。 SERVER「なる」でアップデートなどやってみましたか？
他の人が提案したこのスレッドのソリューションのほとんどはサーバーに適用できますが、そこで試しましたか？
Robocopy（ジャンボありとなし）を使用してテストするとどうなりますか？双方向で高速の場合は、netsharkを使用して、各方向のコピーの先頭にあるSMBセッションヘッダーを確認し、naru-> miyuki設定で何かが異なるかどうかを確認します。

Skyhawk · Answer

私はそれがサーバーからラップトップへのパス上の何かであると思うでしょう、例えば：

ラップトップにパッチされたスイッチポート
スイッチとラップトップ間のイーサネットケーブルまたは接続

@SaucemanSpiffの優れた提案に従って、既知の良好なCAT5EまたはCAT6ケーブルを使用してラップトップをサーバーに直接ケーブル接続してみましたか？関係するインターフェイスの少なくとも1つがギガビットイーサネット（Auto MDI-Xを意味する）をサポートしている限り、特別なクロスケーブルは必要ありません。

chris · Answer

すべてについて、ネットワークカードを全二重、100MBit、自動ではないに設定したと思いますか？

William Hilsum · Answer

あなたはおそらくこの答えを嫌うでしょうが、私はそれを言わなければなりません！

ドライバを更新してみましたか？

私のラップトップ（RealtekベースのNIC）でも同様の問題が発生します。転送速度は約3MB/sですが、サイトからドライバーを最新のものにアップグレードした瞬間に、最大40-50MB/sになります。

Windowsのドライバーが機能するからといって、それが最良であるとは限りません。

Bahrain Admin · Answer

テラコピーを使ってみましたか？私はこれを1年以上にわたってWindowsコピーの標準的な代替品として使用しており、転送速度の向上を示しています:)