[zeromq-dev] WSAWaitForMultipleEvents versus WSAPoll
Steven McCoy
steven.mccoy at miru.hk
Sat Oct 30 13:39:31 CEST 2010
Looks like the problem is a bit bogus and based around inefficiencies of
Sleep(). I tried using Vista+ only routines for various locking methods and
only managed to reduce the jitter by a small margin, albeit welcome
improvement.
Taking heed of the warning on Sleep(0) though I make sure I skip calling for
0ms and make sure I force the highest timer resolution by linking winmm and
calling timeBeginPeriod() with 1ms or the lowest the system supports as per
Microsoft's example code. This leads me to the following improved latency.
2010-10-30 19:29:29 : s=9999.7 avg=368.9 min=177.0 max=5711.0 stddev=434.4 us
o=84.80 i=84.80 mbit
2010-10-30 19:29:31 : s=10000.4 avg=389.0 min=177.0 max=5473.0 stddev=447.4
us o=84.80 i=84.80 mbit
2010-10-30 19:29:33 : s=9996.1 avg=418.9 min=176.0 max=6593.0 stddev=565.2
us o=84.77 i=84.77 mbit
2010-10-30 19:29:35 : s=10004.0 avg=361.8 min=177.0 max=3933.0 stddev=379.9
us o=84.83 i=84.83 mbit
2010-10-30 19:29:37 : s=9999.5 avg=365.8 min=177.0 max=4524.0 stddev=380.3
us o=84.80 i=84.80 mbit
2010-10-30 19:29:39 : s=10000.1 avg=395.8 min=178.0 max=5608.0 stddev=469.6
us o=84.80 i=84.80 mbit
i.e. the average latency is ten times faster and the minimum is consistently
below 180us.
It still doesn't allow me to run consistently at 30,000 packets-per-second
(pps), and setting NetworkThrottlingIndex as per KB948066 does not help.
http://support.microsoft.com/kb/948066
--
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101030/b69ad77b/attachment.htm>
More information about the zeromq-dev
mailing list