[zeromq-dev] zmq::poll timeout returns immediately on MacOS/X 10.5

Marcin Gozdalik gozdal at gmail.com
Fri Jun 11 14:12:11 CEST 2010


2010/6/11 Marcin Gozdalik <gozdal at gmail.com>

> 2010/6/11 Marcin Gozdalik <gozdal at gmail.com>
>
> 2010/6/11 Steven McCoy <steven.mccoy at miru.hk>
>>
>>> On 11 June 2010 16:11, Steven McCoy <steven.mccoy at miru.hk> wrote:
>>>
>>>> "It takes 324 cycles per call to complete 1 million GTOD calls without
>>>> RDTSCP and 221 cycles per call with the capability."
>>>>
>>>>
>>>>
>>> Compare this with HPET which I clock about 500ns when using mmap(), it
>>> would be significantly slower when using libc IO to read from the device.
>>>
>>> WIthout RDTSCP or HPET you can use CPUID+RDTSC or complicated tracking of
>>> current cores and TSC offsets, etc, which is absolutely broken on
>>> hyperthreading processors.
>>>
>>
>> A micro-benchmark comparing various time-tracking methods (for FreeBSD but
>> probably easily portable) was posted on
>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/2008-06/msg00000.htmlOn Linux the fastest is clock_getttime(CLOCK_MONOTONIC_COARSE) (recently
>> introduced in 2.6.3X - see http://lwn.net/Articles/347811/)
>>
>
>
Another test under Ubuntu 9.10:

Linux 2.6.31-21-server #59-Ubuntu SMP Wed Mar 24 08:26:06 UTC 2010 x86_64
GNU/Linux

processor : 0..7
model name : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
cpu MHz : 2668.000

./bench_time 10000000 | sort -rnk1
Timing micro-benchmark.  10000000 syscall iterations.
Avg. us/call Elapsed Name
0.136119 1.361193 clock_gettime(2/CLOCK_PROCESS_CPUTIME_ID)
0.120999 1.209985 clock_gettime(2/CLOCK_THREAD_CPUTIME_ID)
0.079380 0.793799 clock_gettime(2/CLOCK_MONOTONIC_RAW)
0.050887 0.508871 clock_gettime(2/CLOCK_REALTIME_COARSE)
0.050696 0.506963 clock_gettime(2/CLOCK_MONOTONIC_COARSE)
0.033664 0.336642 gettimeofday(2)
0.032783 0.327831 time(3)
0.030980 0.309803 clock_gettime(2/CLOCK_REALTIME)
0.030776 0.307761 clock_gettime(2/CLOCK_MONOTONIC)
Value from time(3): 1276258258
Last value from gettimeofday(2): 1276258258.400474
Last value from clock_gettime(2/CLOCK_THREAD_CPUTIME_ID): 5.662877003
Last value from clock_gettime(2/CLOCK_REALTIME_COARSE): 1276258259.038135643
Last value from clock_gettime(2/CLOCK_REALTIME): 1276258259.038135643
Last value from clock_gettime(2/CLOCK_PROCESS_CPUTIME_ID): 4.453014117
Last value from clock_gettime(2/CLOCK_MONOTONIC_RAW): 3634311.757226924
Last value from clock_gettime(2/CLOCK_MONOTONIC_COARSE): 3634311.757226924
Last value from clock_gettime(2/CLOCK_MONOTONIC): 3634617.143380301

My statement that CLOCK_MONOTONIC_COARSE should be the fastest is apparently
not true ;)

-- 
Marcin Gozdalik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100611/d98ad87b/attachment.html>


More information about the zeromq-dev mailing list