[ntp:questions] micro-optimization

Martin Burnicki martin.burnicki at meinberg.de
Wed Mar 11 10:35:16 UTC 2009


Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
> Martin Burnicki wrote:
>> As a consequence of the above I'd say using RDTSC directly instead of QPC
>> is a step in the wrong direction. From what I've seen adding the
>> /usepmtimer switch should fix problems on systems where TSC is used even
>> though it is not reliable.
> 
> TSC has one huge advantage, in that it costs almost nothing to read it
> (10-25 clock cycles depending upon cpu model), but power frequency
> adjustments and especially SMP systems cause trouble.
>> 
>> This should also make it obsolete to nail down all threads to a single
>> CPUm as suggested in bug #1124:
>> https://support.ntp.org/bugs/show_bug.cgi?id=1124
>> 
>> Or am I missing something?
> 
> The alternate timers, being bus-based, cost one or two orders of
> magnitude more time to query, so for a system which needs very frequent
> timing info, the overhead needed to make RDTSC useable (processor
> locking, frequency stepping callbacks etc) can make sense.
> 
> NTP in client modus is almost certainly not in this category, with less
> than 1000 calls per second.

Right, that's why I think continuing to use QPC.

Here, 2 consequent QPC calls retrun a difference of ...
350..400 ns using TSCs on an Intel 3 GHz CPU 
1.6..1.9 us using the PM timer on my AMD x64 4400+

I think the difference is not relevant for NTP.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list