[ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
greigaln at netscape.net
Thu Jan 21 12:27:41 UTC 2010
I'll try a few experiments. Motherboard is ASRock ALiveNF6p-VSTA, a
fairly mainstream manufacturer board with NVIDIA Chipset and onboard
graphics. That or very similar architecture boards are quite widely in use.
I do have a copy of OpenSolaris I stuck on another partition to play
with some time ago so I can install NTPD on it and watch what happens
when I get a chance. Might also try a fresh install of Windows on
another parition to see if I still see the problem.
In the meantime what I've noticed is that if I fire up most multimedia
apps (web browser plugins for example) then the timer resolution gets
set to 1.953 ms or 3.906 ms and in this case NTPD DOES MANAGE TO SYNCH
THE TIME!! (although it drifts a bit before resynching) It seems that it
is only when the timer interval drops to 0.977 ms either set by NTPD or
something else (Windows Media player sets it to this for example) that
we enter a time-warp.
So in summary
Current timer interval: 15.625 ms - No problem
Current timer interval 3.906 ms - No problem
Current timer interval 1.953 ms - No problem
Current timer interval 0.977 ms - Wild time drift
More digging when I get a chance.
Martin Burnicki wrote:
> David J Taylor wrote:
>> "Alan" <greigaln at netscape.net> wrote in message
>> news:Z9I5n.58805$Q36.5787 at newsfe19.ams2...
>>> Would like to get to the bottom of this as well. Using 4.4.6-o with -M ,
>>> I get "Frequency error 3030 PPM exceeds tolerance 500 PPM". Considering
>>> that without =M the frequency modification is only about 5 PPM then
>>> obvioulsy something very strange is going on. It seems that even if the
>>> timer precision is increased by another program then time immediately
>>> starts to drift rapidly by hundreds of milliseconds.
> Yes, looks like timing is seriously broken on your hardware.
> Dave Hart, isn't there a way to force disabling time interpolation with your
> binaries even if the system time increments in 15.625 ms steps?
> Maybe this could be wort a try in this special case.
>> Our experience was that the switching between normal and high-resolution
>> timers caused steps of many milliseconds (I don't recall the exact figure)
>> which really messed up NTP. So either run with no MM timers at all, or
>> run with the MM timers permanently enabled, and NTP recognises that
>> change, and adjusts accordingly. Have NTP start the MM timers was one
>> solution, and hence the -M option.
>> It might be helpful to know what the event log says with both sets of
>> startup parameters, as there may be a clue there which Dave Hart, the
>> person closest to this code, can interpret.
>> I must confess to having nagging doubts about AMD (but with no good
> AFAIK the CPU type (Intel or AMD, CPU family ...) should not matter if the
> PM timer is used for QPC instead of the TSCs.
> However, as I've mentioned in a different reply, the problem may be due to a
> fault chipset.
> The Linux kernel identifies quite a number of problematic hardware and
> displays appropriate warnings at startup, so booting a current Linux system
> (maybe from a Live CD) on that machine and watching the startup messages
> *may* give some hints.
>> about whether you have another program setting the time (check
>> that w32time.exe is not running - Show Processes from all users), and
>> perhaps something in the BIOS. One final idea (which there was no option
>> on my test system) might be to start with just one CPU active in the BIOS.
> I doubt the problem may be due to a different time sync program running
> since the problem occurs if and only if the MM timer tick rate is changed.
More information about the questions