![Ping 测试立即回复,但报告显示响应时间极长](https://linux22.com/image/569344/Ping%20%E6%B5%8B%E8%AF%95%E7%AB%8B%E5%8D%B3%E5%9B%9E%E5%A4%8D%EF%BC%8C%E4%BD%86%E6%8A%A5%E5%91%8A%E6%98%BE%E7%A4%BA%E5%93%8D%E5%BA%94%E6%97%B6%E9%97%B4%E6%9E%81%E9%95%BF.png)
我仍在尝试验证我的假设,即该问题可能只出现在托管在同一物理 Hyper-V 主机上的服务器上,但至少我发现经常出现(虽然是间歇性的)从其他服务器尝试 ping 某些服务器并得到奇怪响应的情况。标准 Windows ping 工具将立即(比您预期的 < 1ms 回复时间快得多)报告所有四个回复,数字为数万毫秒。
运行ping -n 1000 fs1.nisgaa.net > ping-fs1.log
大约在10-15秒内完成。
1. The first line: Reply from 10.3.0.17: bytes=32 time=85546ms TTL=128
2. The next ~450: Reply from 10.3.0.17: bytes=32 time=63979ms TTL=128
3. The next two: Reply from 10.3.0.17: bytes=32 time<1ms TTL=128 (these lines actually take a second to spit out, unlike the above, which appear instantly)
4. Next two: Reply from 10.3.0.17: bytes=32 time=85546ms TTL=128
5. Next two: Reply from 10.3.0.17: bytes=32 time<1ms TTL=128
6. Next one: Reply from 10.3.0.17: bytes=32 time=63980ms TTL=128
7. Next five: Reply from 10.3.0.17: bytes=32 time<1ms TTL=128
8. Next three: Reply from 10.3.0.17: bytes=32 time=91472ms TTL=128
9. Next ~75: Reply from 10.3.0.17: bytes=32 time=63980ms TTL=128
0. Next four: Reply from 10.3.0.17: bytes=32 time<1ms TTL=128
1. Next one: Reply from 10.3.0.17: bytes=32 time=85546ms TTL=128
2. Next one: Reply from 10.3.0.17: bytes=32 time<1ms TTL=128
3. Next one: Reply from 10.3.0.17: bytes=32 time=85546ms TTL=128
4. Next 15: Reply from 10.3.0.17: bytes=32 time=63980ms TTL=128
等等,它声称这些大块重复的数据需要几分钟,但会立即报告,然后是少量<1ms的响应,正如我所料。
有什么想法可能导致这种情况发生吗?
答案1
由于虚拟处理器不会连续运行,因此在虚拟机中测量少量时间可能非常困难。如果时间计算出现偏差,我一点也不会感到惊讶。
如果真的是立即报告的话,那么 64 到 85 秒的测量结果显然是错误的。
答案2
我一直有完全相同的问题并发现以下博客文章:
http://blogs.msdn.com/b/tvoellm/archive/2008/06/05/negative-ping-times-in-windows-vm-s-whats-up.aspx
这只是一篇简短的博客文章,可能有助于您解决一些客户在 Hyper-V VM 下运行时遇到的问题。该问题是多处理器客户机上的负 ping 时间。
如果您在多处理器 W2k3 客户操作系统中看到负的 ping 时间,您可能考虑在 boot.ini 文件中设置 /usepmtimer。
根本问题来自 Win32 QueryPerformanceCounter 函数。默认情况下,它使用名为 TSC 的时间源。这是一个 CPU 时间源,本质上是计算 CPU 周期。每个(虚拟)处理器的 TSC 可能不同,因此无法保证在一个处理器上读取 TSC 与在另一个处理器上读取 TSC 有任何关系。这意味着在不同 VP 上连续读取 TSC 实际上可能会倒退。Hyper-V 保证 TSC 不会在单个 VP 上倒退。
因此,这里负 ping 时间的问题在于时间源使用的是 QueryPerformanceCounter,而 QueryPerformanceCounter 使用的是 TSC。通过使用 /usepmtimer boot.ini 标志,您可以将 QueryPerformanceCounter 的时间源从 TSC 更改为 PM 计时器,这是一个全局时间源。
这些症状还会影响依赖于 的任何内容QueryPerformanceCounter
,例如点网System.Diagnostics.StopWatch
类。
更新- 我们友好的 IT 人员按照说明更新了我们的虚拟机,并且解决了该问题。