![更新](https://linux22.com/image/490457/%E6%9B%B4%E6%96%B0.png)
更新
好的,我尝试了以下答案,但没有任何变化。我已将笔记本电脑中的芯片组识别为 NVIDIA nForce 520。我下载了最新的 Vista x64 nForce 520 驱动程序(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 范围。笔记本电脑之间的两个交换机也支持巨型帧。
当我将文件从我的服务器复制到我的笔记本电脑时,它们以蜗牛般的速度运行(通常不到 1 MB/秒),而通过相同交换机的其他设备可以以更高的速度传输(45 - 55 MB/秒)。从笔记本电脑复制到服务器的速度似乎更快,但远不如应有的速度。
涉及的机器
- Miyuki:有问题的笔记本电脑。Windows 7 x64 RTM。HP Pavilion dv9700 CTO。使用 NVIDIA nForce 10/100/1000 Mbps 以太网适配器。(视频是 GeForce 8400M GS)
- Naru:带有文件的服务器。自定义 Windows Server 2008 R2 x64 SP2。使用 D-Link DGE-560T PCI Express 千兆适配器。
- CC:HTPC 使用同一个交换机,没有问题。Windows Vista x86 SP2。使用板载 Realtek RTL8168B/8111B PCI-E GBE 适配器。
拍摄这些图像时,巨型帧已全部关闭。
图像
从笔记本电脑发起复制
服务器 -> 笔记本电脑
(来源:gibixonline.com)
笔记本电脑 -> 服务器
从服务器发起复制
服务器 -> 笔记本电脑
(来源:gibixonline.com)
意外的是,让服务器将文件从笔记本电脑复制到自身,其速度达到了我所期望的水平。(笔记本电脑 -> 服务器)
(来源:gibixonline.com)
我之前说过,同一台交换机上的另一台机器没有这个问题。由于这是在高清电视上显示的,所以打开了高 DPI。
服务器 -> HTPC
(来源:gibixonline.com)
自然,我决定进行测试,看看我的笔记本电脑和 HTPC 之间的速度如何。不幸的是,它们完全符合我的预期。HTPC
-> 笔记本电脑
(来源:gibixonline.com)
最后说明
我已经尝试了所有能想到的方法。此时甚至关闭了巨型帧,但似乎没有任何效果。我尝试关闭防病毒保护来更换我使用的电缆。目前使用的所有电缆都是我制作的 CAT-5e。我尝试从 HTPC 上取下电缆并将其插入我的笔记本电脑,看看电缆是否有问题。有问题的两个交换机是 D-Link DGS-1216T 和支持巨型帧的“哑”交换机,即 D-Link DGS-2208。
答案1
尝试禁用 Windows 的自动调整功能。
在 CMD 窗口中:
netsh interface tcp set global autotuning=disabled
重新运行测试,看看是否注意到性能有所改善。我在家里的几台运行 Windows 7 的笔记本电脑上也做过这个测试,效果不错。
如果情况变得更糟,或者您没有注意到任何改善,您可以通过以下方式重新启用自动调整:
netsh interface tcp set global autotuning=normal
答案2
这似乎是 Windows 7 的一个大问题。一些游戏玩家已经抱怨过这个问题。
- 从命令提示符(通常在所有程序 -> 附件 -> 命令提示符中)运行“regedit”
- 浏览到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces
- 浏览接口下的项目,直到找到一个具有与您想要影响的网络接口匹配的 IPAddress 条目的项目(通常 LAN IP 地址以 192.168 或 10.0 开头);请注意,如果您的 IP 地址是由 DHCP 服务器自动分配的,您可能需要查找匹配的 DhcpIPAddress 而不是 IPAddress
- 右键单击接口并选择新建> DWORD(32 位)值,将其命名为“TcpAckFrequency”
- 右键单击新的 TcpAckFrequency 值并选择修改,输入“1”(应选择十六进制单选按钮)
- 右键单击接口并选择新建> DWORD(32 位)值,将其命名为“TCPNoDelay”(请注意,这次 TCP 全部大写 - 这是故意的)
- 右键单击新的 TCPNoDelay 值并选择修改,输入“1”(应选择十六进制单选按钮)
- 验证 TcpAckFrequency 和 TCPNoDelay 现在是否显示在适配器的属性列表中,类型为 REG_DWORD,值为 0×00000001
- 退出 regedit 并重新启动(必须重新启动才能使更改生效!)
- 玩游戏,享受新的低 ping 值
这使得我在大多数游戏中的 ping 值从 200-300 毫秒降低到 50-60 毫秒,这与我通过 tracert 到游戏服务器看到的延迟相匹配。
答案3
为了验证笔记本电脑是否有故障,运行 ubuntu live cd,将 iperf 安装到 ramdisk 上并运行测试。
这至少应该测试它的网络方面。
答案4
我以前在其他 AV 产品上也遇到过这种情况。我遇到的问题是 SMB,即使“禁用”,AV 产品也会受到干扰。它在 wireshark 中显示的结果与您类似。以下是我检查的众多网站之一,以找到根本原因:Symantec SMB 问题另一个:SMB2 与 NTP 发生故障
此外,您可以尝试禁用/更改 SMB 中的所有或部分设置。我甚至会考虑在操作系统上禁用 v2。查看这篇文章描述 Win Vista 中的 SMB 问题以及这个微软的链接概述了有关 SMB 注册设置的一些技术数据。
我知道您提到了 Avast,但我看到类似的 wireshark 结果也纯属巧合。请注意,在我的情况下,除了文件传输之外,其他一切似乎都运行正常。