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

Question

我有一个使用套接字的 .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 并得到了相同的结果

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

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

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/

Answer 1

它实际上是行为不端的“快速”机器。 Windows 中的计时器具有由时钟中断率决定的分辨率。正确配置的机器每秒滴答 64 次，这使得计时器的精度为 15.625 毫秒。滴答之间处理器的正常状态是断电，停在 HLT instruction .在此期间它当然无法观察时间的流逝。

您通常可以通过运行 powercfg.exe /energy 找到导致机器行为异常的程序。来自提升的命令报告。这通常会指出与媒体相关的程序、音频驱动程序或插件通常是罪魁祸首。 Google 的 Chrome 因这样做而臭名昭著，即使在 battery-powered devices 上也是如此。 ，你可能会对电池生命周期做最坏的事情。

Socket.Poll() 建议的解决方案当然被大大夸大了，这来自底层 select()套接字函数。追溯到 1980 年代发明套接字时的 Unix，那时功耗绝对不是问题。

这应该不是问题，毕竟没有什么可做的，所以花多长时间应该没有关系。并且您通常不应该使用该方法，而是使用 Socket.BeginSend/Receive() 依赖异步 I/O，非常高效。如果您寻求快速修复，那么您也可以做坏事并重新编程时钟中断率。您必须调用 timeBeginPeriod() function .请求 1 毫秒。并在您不再需要时调用 timeEndPeriod()。