[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.
David J Taylor
david-taylor at blueyonder.co.uk.invalid
Thu Mar 15 08:34:00 UTC 2012
"Ron Frazier (NTP)" <timekeepingntplist at c3energy.com> wrote in message
news:4F61168B.8030804 at c3energy.com...
[]
> PS to my prior message.
>
> I don't think the problem so much is the delay to the internet servers,
> or even to get out of my house. NTPD is supposed to take care of that
> as long as it's pretty much symmetrical. I think the problem is that
> the Windows clock is like a wild tiger that doesn't want to be tamed and
> which is running every which way.
Windows is not designed as a real-time OS, and its timekeeping is not as
good as other systems, but with one good local server you can sync Windows
PCs to that server with something like: minpoll 5 maxpoll 5. Obviously,
you would not do that over the Internet without permission.
> For whatever reason, cpu load, heat, cosmic vibrations, whatever, the
> intrinsic frequency of the windows clock is always changing. In order
> to avoid beating up on the internet servers too much, I have to poll
> them at least every 4 minutes apart. If you let it, NTPD will extend
> that out to 16 minutes or more. So, when the clock source is polled,
> say the PC clock is too fast, so NTPD slows it down. Then, when you
> poll the clock source again, say the PC clock is too slow, so NTPD
> speeds it up. Because of the varying intrinsic frequency of the clock,
> you can never find a clock speed that just works, because then the
> system goes and changes, by changes in the oscillator, how much time
> passes at those particular settings. It's a battle you cannot win. By
> polling my GPS every 8 seconds, I can keep the clock under control based
> on it's current needs which are varying second by second. Of course,
> when discussing internet servers, 30 ms of jitter doesn't help any.
Windows itself doesn't vary the clock frequency unless you enable the
power-saving frequency of the chipset. What I /have/ seen on Windows is
poorly written third-party drivers which hold off interrupts for too long
or are otherwise badly behaved, and chipsets or motherboards which are
equally unfriendly. I have one application which can ruin timekeeping,
given half a chance! Note the scale on PC Gemini which has an AMD
processor on an ASUS A8N SLI motherboard. +/- 100 ms, not +/- 3 ms. I
see large offset steps, which NTP tries its best to keep up with.
[]
> The point is, that it's a continually moving target. The windows clock
> is the same way. It never runs at the same frequency from minute to
> minute. Even if you get it running right one minute, it's wrong the
> next.
All PCs are a continually moving target! Some move more than others, but
give a good PPS source, the major variation on even Windows PCs is due to
temperature fluctuations.
> Let's take, for example, the TAZ computer I mentioned earlier. Forget
> GPS for the moment. With the default settings, NTPD will eventually be
> polling the internet server every 16 minutes. The problem is not
> exclusively that there is jitter in the time retrieved from the time
> server. Let's also forget that for the moment. Say we poll the
> internet server and it says the time is exactly 12:00:00. Rounding to
> the seconds level just for simplicity, say my clock says 12:00:02, so
> I'm 2 seconds fast. So, we slow down the clock by tweaking its
> parameters. Then, we wait 16 more minutes. Now the time server says
> 12:16:00. Say my clock says 12:15:57. Now, I'm 3 seconds slow, so we
> speed the clock back up. Now, theoretically, just like my pendulum
> clock, I should be able to get the parameters dialed in so the clock
> keeps time. However, behind the scenes, the intrinsic operational speed
> changed. While I'm sure I'm butchering the internal technicalities,
> let's say the clock has a speed knob, and if we set the speed knob to a
> value of 100, the the clock will count exactly 1 second while exactly 1
> second passes. If this stayed true, NTPD would eventually set the speed
> knob at 100 and everybody would be happy. But the intrinsic speed of
> the oscillator changed, so that now setting that knob at 100 now makes
> the clock think 1.03 seconds has passed when, in actuality, 1 second has
> passed. So the clock is running fast. So, NTPD dials the speed knob
> back to 97. But now, the oscillator has changed again so that a setting
> of 97 now makes the clock think that .95 seconds have passed, when, in
> actuality, 1 second has passed. This is why I'm getting such wild
> oscillation in the graph. No matter what NTPD does to tweak the clock
> speed, and no matter how accurate that is at the time, that adjustment
> never has the same effect the next time the time server is polled. Just
> as setting the screw on the pendulum of my mechanical clock doesn't have
> the same effect tomorrow as it does today. There will never be a
> setting that just works.
> I don't think it's a game you can win on a standard windows computer.
> So, I'm not even inclined to play the internet NTP server game. So, by
> polling my GPS every 8 seconds, the computer has much less time to
> drift, no matter what the oscillator is doing, and it needs much less
> correction. Then, NTPD can adapt dynamically and almost instantly to
> put in whatever adjustments are needed at that moment in time. The
> overall net effect, assuming the GPS is accurate, is that the computer's
> clock is never more than 10 ms away from GPS time, rather than being 50
> ms away from an internet time server's time. With PPS, I could get it
> much better still.
>
> Sincerely,
>
> Ron
Basically you have a trade-off between frequency error and time offset.
IIRC, polling quickly will reduce the offset, but you get greater
frequency variations. Once you have one good PPS-synced server, you will
be able to sync other PCs to that (within the limits of Wi-Fi). There are
folk here who may even pipe PPS signals to many PCs to sync them up. I
have a very minor version of that idea as my GPS 18 LVC send output is
connected to two PCs in parallel - both with RS-232 ports. They are PCs
Pixie and Bacchus on the graphs here:
http://www.satsignal.eu/mrtg/performance_ntp.php
Note how high CPU causes a temperature shift on Bacchus, and hence up to 1
ms offset shift. That's from a poorly written disk defragmentation
facility, but the newer free ones mostly don't work on Windows 2000
Server!
http://www.satsignal.eu/mrtg/performance_bacchus.php
Cheers,
David
More information about the questions
mailing list