[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.
Ron Frazier (NTP)
timekeepingntplist at c3energy.com
Thu Mar 15 12:47:27 UTC 2012
On 3/15/2012 4:34 AM, David J Taylor wrote:
> "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.
I mainly meant that operating conditions will vary the frequency of the
oscillator. Speaking of which, is there a way to run ntpd and have it
NOT adjust the clock at all, but still generate stats files, so I can
monitor the clock frequency just based on the computer usage and nothing
Can you elaborate on that power saving frequency thing? Is that the
thing in the control panel where you set the minimum and maximum cpu
>> 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.
> 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:
> 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!
Wow, if I'm reading that graph right in the last link, that cpu usage
spike sent your clock variation from about 100 us to 4000 us. That's
amazing, and frustrating.
I thought all 32 bit Windows had the same kernel. You could try this
defragger. I've had good luck with it, but I'm not sure which older
systems it works on.
Also, check page 78 of this Computer Power User magazine for an article
You can look at their other archives at
http://www.computerpoweruser.com/ - you have to have Flash for this to work
Choose a magazine issue
Click the arrow pointing down on the left toolbar
In the popup window, click the PDF tab
(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such. I don't always see new messages very quickly. If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)
timekeepingdude AT c3energy.com
More information about the questions