[ntp:questions] Frequency Offset

David J Taylor david-taylor at blueyonder.co.uk.invalid
Sat Feb 25 07:31:35 UTC 2012

"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 

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


More information about the questions mailing list