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:
>> 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.
More information about the questions