[ntp:questions] micro-optimization
Terje Mathisen
"terje.mathisen at tmsw.no" at ntp.org
Wed Mar 11 09:19:14 UTC 2009
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.
An NTP server with lots of clients won't be running on Windows anyway. :-)
I do know that Intel intends to make processor-based timers more useful
by setting up a counter which always runs at a fixed rate, independent
of any frequency power stepping. On such a cpu RDTSC would again be the
best choice, but hopefully the OS would realize this and start to use it
for QPC.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the questions
mailing list