Dave, 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 http://support.microsoft.com/kb/833721/en-us 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: http://blogs.technet.com/perfguru/archive/2008/02/18/explanation-for-the-usepmtimer-switch-in-the-boot-ini.aspx 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 systems. 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: https://support.ntp.org/bugs/show_bug.cgi?id=1124 Or am I missing something? Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
