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并得到了相同的结果

为何延误？注册表设置？Ninja Gremlins？

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

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指令上停止.在此期间它当然无法观察经过的时间.

您通常可以通过powercfg.exe /energy从提升的命令报告运行来找到导致计算机行为异常的程序.这通常指出媒体相关的程序,音频驱动程序或插件往往是罪魁祸首.谷歌的Chrome因这样做而臭名昭着,即使是在电池供电的设备上也是如此,你可以对电池寿命做最坏的事情.

Socket.Poll()建议的分辨率当然被夸大了,这来自底层的select()套接字函数.在20世纪80年代发明套接字时,日期又回到了Unix,当时功耗绝对不是一个问题.

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