[ntp:questions] micro-optimization

Martin Burnicki martin.burnicki at meinberg.de
Wed Mar 11 08:55:17 UTC 2009


Dave Hart wrote:
> I have released a new test version of 4.2.4p6 with numerous Windows-
> specific improvements compared to the baseline 4.2.4p6.  Since my last
> release, the most significant change is to read the processor cycle
> counter using the RDTSC instruction directly when it is equivalent to
> QueryPerformanceCounter.  When it is not equivalent, ntpd is allowed
> to roam freely across all logical processors once again.

I've also made some test on different systems. From what I can see QPC can
use different timers each of which has a different clock frequency:

PIT         1.9 MHz
PM Timer    3.579 MHZ
HPET Timer  > 10 MHz, usually 14.318 MHz 
TSC         same as CPU clock

If I look at the frequency reported by QPF then on my Vista system this is
14.318 MHz, so obviously the HPET timer is used to implement QPC.

On a Windows XP *SP2* system with AMD Athlon 64 X2 the QPF value matches the
CPU clock, 2.3 GHz in this case, so this one uses the CPUs' TSCs for QPC.
On *this* system clock interpolation using TSC suffers from TSC values not
being synchronized across CPUs.

The problem can be avoided if I force the system to use the PM timer for
QPC, using the /usepmtimer flag in the Windows boot.ini as suggested in

If I run Windows XP *SP3* on the same machine then QPF returns 3.579 MHZ,
even if the /usepmtimer switch is not used, so the PM timer is preferred to
the TSCs with XP SP3.

On the following page there is an overview which timer is used by which
Windows version / SP level:

Though Windows XP SP 3 is not yet mentioned there it looks like MS is going
to use the PM timer or HPET timer in favour of the TSCs anyway on newer

According to the page mentione above and some other resources on the
internet the AMD driver which should fix the problem also just adds
the /usepmtimer parameter to boot.ini to fiw applications which use QPC,
and also periodically synchronizes the TSCs across CPUs for thos apps which
circumvent QPC and use RDTSC directly. IMHO the latter is a hack which
provides just an ugly workaround.

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.

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?

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list