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


18

更新

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

私は自分のラップトップを兄弟の家に持ち帰り、彼の100Mbitネットワークを介して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 /秒)で転送できます。ラップトップからサーバーネットへのコピーはより高速になりますが、そうすべきではありません。

関係する機械

  • みゆき:問題のあるラップトップ。Windows 7 x64 RTM。HP Pavilion dv9700 CTO。NVIDIA nForce 10/100/1000 Mbpsイーサネットアダプターを使用します。(ビデオはGeForce 8400M GSです)
  • ナル:ファイルのあるサーバー。カスタムWindows Server 2008 R2 x64 SP2。D-Link DGE-560T PCI Express Gigabitアダプターを使用します。
  • CC:問題のない同じスイッチのHTPC。Windows Vista x86 SP2。オンボードのRealtek RTL8168B / 8111B PCI-E GBEアダプターを使用します。

これらの画像が撮影されたとき、ジャンボフレームはすべてオフになっています。

画像

ラップトップから開始されたコピー

サーバー->ラップトップ(ソース: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です。


1
利用可能な帯域幅を測定するためにiperf(iperf win32のgoogle)のようなツールを試してみましたか?私はそれを疑います-しかし、二重のミスマッチがない場合は、チェックする価値があります。
2009

近くのサーバーでpscpのようなものを試して、その速度を確認しましたか?
クリス

1
サーバーとラップトップを相互接続して、スイッチが切り替えられないようにしましたか?
ジョセフ

@ジョセフが言ったことにアーメン。方程式からスイッチを削除してみてください。
ジェレミーフィッサー

回答:


5

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

CMDウィンドウで:

netsh interface tcp set global autotuning=disabled 

テストを再実行し、パフォーマンスの改善に気付いたかどうかを確認します。私の家でWindows 7を実行している2、3のラップトップでこれを行う必要がありましたが、助けになりました。

状況が悪化した場合、または改善に気付かない場合は、次の方法でオートチューニングを再度有効にできます。

netsh interface tcp set global autotuning=normal

3

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

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

これにより、ほとんどのゲームのpingが200〜300ミリ秒から50〜60ミリ秒に減少しました。これは、ゲームサーバーへのトレーサーを介して表示される遅延と一致します。

取られたWindows 7またはVistaのゲームネットワークの遅延を減らします


1
tracertはTCPではなくICMPを使用します。これらのキーはTCP用であるため、ICMPについては何も変わりません。トレーサーで応答時間が改善された理由がわからない
マシューシャトー

まあ、私は先に進んでこれを試しましたが、それでも同じようです。元の質問を、より多くの情報と試したもので更新しています。
ジョシュア

2
マシュー、彼はトレーサーからより良い時間を見たとは言わなかった。彼は、ゲーム内のレイテンシーはトレーサーと同等になると言いました。つまり、TCPトラフィックで観測されるレイテンシーは、正常に機能していたICMPトラフィックのレイテンシーと似ています。
MDMarra

3

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

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


1

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

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


1

他のAV製品でこれに出会ったことがあります。私の問題はSMBにあり、AV製品は「無効」であっても干渉していました。Wiresharkでも同様の結果が示されました。根本原因に到達するためにチェックした多くのサイトの1つは次のとおりです。SymantecSMBの問題と別の問題SMB2がNTPで失敗する

さらに、SMB内のすべてまたは一部の設定を無効化/変更してみてください。OSでv2を無効にすることも検討します。Win Vista内のSMBの問題について説明しているこの記事をご覧ください。Microsoftへのこのリンクでは、SMB reg設定に関する技術データの概要を説明しています

あなたがアバストに言及したことは知っていますが、似たようなWiresharkの結果を見たのはかなり偶然です。私の場合、ファイル転送以外はすべて正常に機能するように見えます。


1

パケット署名を使用しているときに、クライアントがWindowsサーバーと通信する際に問題が発生しました。遅さは経験しませんでしたが、かなり一般的な接続のドロップアウトが発生しました。

私の問題を解決した解決策についてはこちらをお読みください

また、TCP Chimneyの機能を1つずつ無効にして、それらの1つが異常になったかどうかを確認するための提案もありません。


これによっても焼かれました...
ベンキャンベル

1

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

  • ラップトップhddのパーティションのブロックサイズを確認します(小さなブロックサイズは、1つの大きなファイルを転送しようとしたときに、空き領域のシーク時間を低下させる可能性があります)
  • 着信パケットのディスク書き込みをチェックするファイアウォールポリシーのチェック
  • ファイルアクティビティモニターをチェックします(これはアンチウイルスをアンインストールするため、心配する必要はありません)(avastはライブファイルチェックを実行し、ネットワーク転送を少し遅くすることを知っているように..)
  • ターゲットパーティションのデフラグ(再び空き領域の探索について)

他のものが提案されており、助けていないようです:

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

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

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

私は他の解決策を考えることはできません...これが役立つことを願っています...


1

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

Windows 7 Pro、Celeron J1800、Realtek Gigabit 8111CビルトインLANカード。QNAP 453aとMacBook Proのもう一方の端。

Iperf3で測定すると、Windows 7をクライアントに設定して112 mbpsを取得していました(25〜30%のCPU使用率)。サーバーとして設定した場合、39〜41 Mbpsのみで、CPU使用率が50〜100%の間です。帯域幅のテスト時にPCがフリーズするほど悪い。

NASまたはMACにファイルをアップロードまたはダウンロードしているかどうかに関係なく、最大45 Mbpsの上限の通常のファイル転送。

毎秒35〜45メガバイトしか得られませんでした。かなりイライラする!

悪いLANカードドライバーになってしまいました。ドライバーの更新に夢中になっていて、新しいドライバーが利用可能になったときは常にドライバーを更新しました。推測してください、いくつかの更新の後、私のLANカードは遅くなりました。

古いドライバーを削除して、新しいドライバーをインストールするだけだと言う人もいるかもしれません。簡単ですか?試したが、うまくいかなかった。

ここに私の解決策があります:

製造元のWebサイトのOEMドライバーを使用してWindowsをゼロからインストールしました。同様に、私は次のことをしました:

[デバイスマネージャー] / [LANカード] / [詳細設定] / [フロー制御]以外のすべてを無効にします。

[Windowsの機能]で、リモート差分圧縮を無効にします。

現在、平均速度は80〜100 Mbpsです。


0

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


1
「自動ではない」ための+1 :)
dimitri.p 2009

うん、私は私のカードがサポートするすべてのバリエーションを試しました... 10半分、10完全、100半分、100完全、および1000完全。それらのいずれも何らかの形でそれに影響を与えず、スイッチによると、彼らは1000でフルにネゴシエートします。
ジョシュア

10
スイッチを管理できない場合は、絶対にしないでください。片側で全二重を強制し、反対側でautoを強制すると、反対側は半二重になります。次に、パケットを失います(多く...)。管理できないスイッチは自動です。サーバーでautoを維持し、インターフェースが全二重をネゴシエートしたことを確認します。インターフェイスエラーも確認してください。
マチューシャトー

4
「自動ではない」場合は-1。自動ネゴシエートを含む両端(スイッチとNIC)で同じ構成が必要です。
dunxd

5
私は興味があります。方程式からスイッチを削除し、「サーバー」から「ラップトップ」に直接クロスオーバーケーブルを走らせてみましたか?
SpacemanSpiff

0

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

ドライバーを更新しようとしましたか?

ラップトップ(RealtekベースのNIC)で同様の問題が発生し、約3MB / sで転送されますが、ドライバーをサイトから最新のものにアップグレードすると、約40-50MB / sになります

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


ハハ、ええ、実際に私が試した最初のものでした。現在、インボックスWindows 7ドライバーに戻っていますが、最新のnvidiaドライバーも試しました。私が試したことのない唯一のドライバーは、Windows 7ベータ版またはVistaのものです。
ジョシュア

Vistaのものを試してみて、それがどのように機能するかを見てください。Win7のアップデートで修正されたいくつかの小さな問題がありました。ハードウェア用のVistaドライバーをインストールして手動で修正しました。
デイビッドリックマン

0

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

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

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


0
  1. アップデートでPCを打ち負かし、失敗せずにオフサイトでテストしました。SERVER "naru"で更新などを試みましたか?

  2. 他の人によって提案されたこのスレッドのソリューションのほとんどは、サーバーに適用できますが、そこで試してみましたか?

  3. Robocopyを使用してテストする場合(ジャンボありとなし)、どうなりますか?双方向で高速の場合は、netsharkを使用して、各方向のコピーの先頭にあるSMBセッションヘッダーを調べ、naru-> miyukiセットアップで何かが異なるかどうかを確認します。


0

テラコピーを使用してみましたか?私はこれをWindowsコピーの標準的な代替品として1年以上使用していますが、転送速度の改善が示されています:)


-1

暗闇でのショットのようなものですが、それ助けることできる。

  • コントロールパネルの[リモート差分圧縮]を無効にします-プログラムと機能-Windowsの機能をオンまたはオフにします。
  • ネットワークプロパティからIPv6を削除します。LANでIPv6を使用していますか?無効にしない場合。
  • ipconfig /flushdnsCLIでDNSキャッシュをクリアします。

-1

OSの変更が原因である場合は、OSに問題があります。最新のWindows 7 Service Packをインストールし、最新の更新でWindowsを最新の状態に保つようにしてください。そして最高の希望

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.