[ntp:questions] Frequency Offset

Richard B. Gilbert rgilbert88 at comcast.net
Sat Feb 25 21:30:06 UTC 2012

On 2/25/2012 2:31 AM, David J Taylor wrote:
> "unruh" <unruh at invalid.ca> wrote in message
> news:l9S1r.3578$py5.1230 at newsfe09.iad...
> []
>> The problem is that the relevant temperature is not the room
>> temperature, but the temperature inside the box at the crystal. That
>> temp variation is dominated by computer use, not outside air
>> temperature. Thus if one machine was coasting along, and the other was
>> working flat out, the temp variation witll be 10s of degrees C, even if
>> the outside air temp was constant.
> Yes, the computer use is important, but the PCs I have as prime
> startum-1 servers have a constant load, so the variation in room
> temperature dominates.
>> Also, different crystals have different sensitivities, it is true.
>> Anyway ,my comment stands that his 500PPM was not because of tempreture
>> problems.
> Yes, it's one I did not disagree with. What was remarkable to me was
> that, given a constant load, three different PCs showed such a variation
> in frequency. One with about 2 ppm, one with 0.3 ppm, and one with 0.025
> ppm. All crystals are not created equal!
> []
>> On linux of a few years ago (I do not know if it has been fixed, but
>> indirect observations suggests it has) the calibration of the system
>> clock at bootup was problematic and the rate of the system would vary by
>> 100PPM from one bootup to the next. Ie, ntpd would find its remembered
>> clock rate out by 100PPM. It would then take many hours to settle down
>> to its usual us offsets. (see graph near the bottom of page on
>> www.theory.physics.ubc.ca/chrony/chrony.html). This was driving it from
>> a GPS PPS clock with a poll level of 4. With a poll level of 6 to 10 for
>> a network server, the time scale will be longer by a lot (in fact it
>> would probably exceed the 500PPM limit and also suffer steps in the
>> clock as it exceeded 128ms offset).
>> That yours settled down quickly in your situation does not mean that
>> ntpd always settles down nicely and quickly.
> Well, I've not seen the behaviour you observed, on any on my FreeBSD or
> Windows systems. The ntp.drift file is honoured at startup, and not
> tampered with until NTP has been up for one hour. Perhaps if you were
> repeat your test with a more modern NTP and operating system you would
> get a different result? But I don't think that anyone is claiming that
> you will get microsecond-level offset within minutes of operation from
> boot.

Get ready for a shock.  NTPD needs thirty minutes or more to get a 
reasonable facsimile of the correct time.  To get the microseconds 
right, NTPD needs more like ten hours!  It's not a very good fit for 
running 9AM to 5PM.  You set it running and leave it running 24x7!

If you are constrained to run 9:00AM to 5:00PM you may wish to check out 
a program called "CHRONY" or something like that.  It has much faster 
convergence.  I suspect that you will sacrifice something for that speed!

More information about the questions mailing list