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" <[email protected]> wrote in message
news:[email protected]...
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.
Alan,
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
reason),
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.
Martin
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
