Socket.Poll已经疯狂变时滞在不同的机器 [英] Socket.Poll has wildly varying delay on different machines
问题描述
我已经有了一个.NET 2.0客户端应用程序，我继承了使用套接字。服务器在iSeries上运行。我有计算机尝试使用客户端应用程序和正在经历的滞后。在计算机上遇到滞后我已经确定，Socket.Poll方法需要较长时间。
I've got a .net 2.0 client app I've inherited that uses sockets. Server is running on an iSeries. I've got computers that try to use the client app and are experiencing lag. On a computer experiencing "lag" I've determined that the Socket.Poll method is taking longer.
下面是（我认为）我知道。
Here is how(i think) I know.
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());
日志从一台计算机，没有滞后
log from a computer with no lag
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
从一台计算机登录与滞后
log from a computer with lag
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位。一个是从盘（无滞后）的全新副本，另一台电脑是企业形象（滞后）。两台计算机是千兆以太网。
Both computer are windows 7 64 bit. One is a fresh copy from the disk (no lag), other computer is corporate image(lag). Both computers are gigabit ethernet.
我有两个残疾人的防火墙，他们都正在运行的Symantec Endpoint 12，配置相同。我已经去SEP一起，得到同样的结果。
I've disabled firewalls on both and they both are running Symantec Endpoint 12, configured identically. I've removed SEP all together and get the same result
为什么延误？注册表设置？忍者小鬼？
Why the delay? Registry setting? Ninja Gremlins?
编辑 转出使用秒表类时序
EDIT switch out to use the stopwatch class for timing
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.word$p$pss.com/2013/07/08/windows-timer-resolution-megawatts-wasted/
推荐答案
这实际上是快的机器，是行为不端。在Windows计时器有一个年代由时钟中断率确定的分辨率。正确配置的机器蜱每秒64次，这使得定时器15.625毫秒的准确性。蜱的处理器的正常状态被关机状态，停在一个 HLT指令。在这当然不能观察到时间的推移。
It is actually the "fast" machine that is misbehaving. Timers in Windows have a resolution that's determined by the clock interrupt rate. A properly configured machine ticks 64 times per second, that makes the accuracy of a timer 15.625 msec. The normal state of the processor between ticks is to be powered-off, stopped on a HLT instruction. During which it of course can't observe time passing by.
您通常可以发现，通过从提升命令报告运行的Powercfg.exe /能源使机器无法正常运作程序。这通常查明媒体的相关程序，音频驱动程序或插件往往是罪魁祸首。谷歌的Chrome浏览器是臭名昭著的这样做，即使在电池供电的设备，最糟糕的事情你可以做，以延长电池寿命。
You can usually find the program that causes the machine to misbehave by running powercfg.exe /energy from an elevated command report. This usually pinpoints a media related program, audio drivers or plugins are often to blame. Google's Chrome is notorious for doing this, even on battery-powered devices, worst possible thing you could do to battery life.
由Socket.Poll（）建议的分辨率当然是大大夸大了，这个来自底层的<一个href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx">select() socket函数。可以追溯到UNIX在20世纪80年代时，插座被发明，耗电量绝对不是一个问题当时的情况。
The resolution suggested by Socket.Poll() is of course greatly overstated, this comes from the underlying select() socket function. Dates back to Unix in the 1980s when sockets were invented, power consumption was definitely not a concern back then.
本的应该的不成为一个问题，毕竟没有什么可以做，所以应该没有关系了多长时间。你应该不是一般的使用方法，但依赖于异步I / O与Socket.BeginSend /接收（），效率非常高。如果你在寻找一个快速解决方案，那么你可以做的恶事，以及和编程时钟中断率。你要的PInvoke的 timeBeginPeriod（）函数。问1毫秒。而PInvoke的timeEndPeriod（）时，你不需要它了。
This ought to not be a problem, after all there was nothing to do so it should not matter how long it took. And you should not in general use the method but rely on asynchronous I/O with Socket.BeginSend/Receive(), very efficient. If you look for a quick fix then you can do the evil thing as well and reprogram the clock interrupt rate. You have to pinvoke the timeBeginPeriod() function. Ask for 1 msec. And pinvoke timeEndPeriod() when you don't need it anymore.
这篇关于Socket.Poll已经疯狂变时滞在不同的机器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
