[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