[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
> 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
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