Socket.Poll 在不同机器上的延迟差异很大

我继承了一个使用套接字的 .net 2.0 客户端应用程序。服务器在 iSeries 上运行。我的计算机尝试使用客户端应用程序但遇到延迟。在遇到“滞后”的计算机上，我确定 Socket.Poll 方法花费的时间更长。

（我认为）我是这样知道的。

MyApp.WriteLogEntry("CS: START check for readable socket");
start = DateTime.Now;
readable = ControllerSocket.Poll(500, SelectMode.SelectRead);
end = DateTime.Now;
MyApp.WriteLogEntry("CS: END check for readable socket");
elapsed = end.Subtract(start);
MyApp.WriteLogEntry("Elapsed TotalMilliseconds = " + elapsed.TotalMilliseconds.ToString());  

从计算机登录，无延迟

10.04.22.994427|CS: START check for readable socket
10.04.22.997427|CS: END check for readable socket
10.04.22.997427|Elapsed TotalMilliseconds = 1.0001

从有延迟的计算机登录

10.03.30.729816|CS: START check for readable socket
10.03.30.745432|CS: END check for readable socket
10.03.30.745432|Elapsed TotalMilliseconds = 15.6152

两台电脑都是windows 7 64位。一台是磁盘上的新副本（无延迟），另一台计算机是公司映像（延迟）。两台计算机都是千兆以太网。

我已禁用两者上的防火墙，并且它们都运行 Symantec Endpoint 12，配置相同。我已将 SEP 全部删除并得到相同的结果

为什么延迟？注册表设置？忍者小魔怪？

编辑 切换到使用秒表类进行计时

MyApp.WriteLogEntry("CS: START check for readable socket");
stopwatch.Start();
readable = ControllerSocket.Poll(500, SelectMode.SelectRead);
stopwatch.Stop();
MyApp.WriteLogEntry("Elapsed TotalMilliseconds = " + stopwatch.Elapsed.ToString());            
MyApp.WriteLogEntry("CS: END check for readable socket");   

11.27.30.012079|CS: START check for readable socket
11.27.30.013079|Elapsed TotalMilliseconds = 00:00:00.0000696
11.27.30.013079|CS: END check for readable socket

11.28.30.518912|CS: START check for readable socket
11.28.30.534512|Elapsed TotalMilliseconds = 00:00:00.0148936
11.28.30.534512|CS: END check for readable socket

好读：http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/ http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

实际上是“快速”机器出了问题。 Windows 中的计时器具有由时钟中断率决定的分辨率。正确配置的机器每秒滴答 64 次，这使得计时器的精度为 15.625 毫秒。处理器在时钟周期之间的正常状态是断电、停止HLT指令 http://en.wikipedia.org/wiki/HLT。在此期间它当然无法观察到时间的流逝。

您通常可以通过运行来找到导致机器行为异常的程序powercfg.exe /energy来自高级指挥部的报告。这通常可以查明与媒体相关的程序、音频驱动程序或插件通常是罪魁祸首。谷歌的 Chrome 因这样做而臭名昭著，即使在电池供电的设备 http://blog.codinghorror.com/why-does-windows-have-terrible-battery-life/，你可能对电池寿命做的最糟糕的事情。

Socket.Poll() 建议的分辨率当然被大大夸大了，这来自底层select() http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx套接字功能。追溯到 20 世纪 80 年代的 Unix，当套接字被发明时，功耗在当时绝对不是一个问题。

This ought这不是什么问题，毕竟没什么可做的，所以花多长时间应该没关系。一般情况下，您不应该使用该方法，而是依赖于 Socket.BeginSend/Receive() 的异步 I/O，非常高效。如果您寻求快速修复，那么您也可以做坏事并重新编程时钟中断率。你必须pinvoketimeBeginPeriod() 函数 http://pinvoke.net/default.aspx/winmm/timeBeginPeriod.html。请求 1 毫秒。当你不再需要它时，pinvoke timeEndPeriod() 。