[ntp:questions] Frequency Offset
unruh at invalid.ca
Fri Feb 24 20:10:57 UTC 2012
On 2012-02-24, David J Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
> "unruh" <unruh at invalid.ca> wrote in message
> news:20Q1r.6801$Ai4.3345 at newsfe18.iad...
>> Do you mean >500PPM?
>> If you were running linux, you could use the adjtimex program and the -t
>> or --tick adjustment to change the tick value of your system clock.
>> each value of 1 adjustment speeds up or slows down the clock by about
>> You can use that to get the clock within the +- 500PPM range that ntpd
>> can adjust. chrony uses it automatically.
> .. and a similar facility exists in Windows by setting the
> NTPD_TICKADJ_PPM environment variable
>> Temperature sensitivity is usually in the "less than 1PPM per degree C"
>> so you would have had to be expriencing quite a heat wave (500 degrees
>> C) to have temperture be a factor. I suspect other things might have
>> been more urgent worries then.
> Frequency variation from mean of three PCs in the same room is remarkable
> different here:
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.
Also, different crystals have different sensitivities, it is true.
Anyway ,my comment stands that his 500PPM was not because of tempreture
> - Dell 4400
> typically +/- 0.7 ppm, but -1.5ppm one day
> - home built Pentium 4 HT system with ASUS P4P800 motherboard
> typically -0.2 to + 0.1 ppm
> - recent PC with quad-core Intel and ASUSTeK P7P55 LX motherboard
> -0.015 to + 0.009 ppm
>>> One of my desktop systems, p4-2667, has just taken two
>>> days to get to an offset of under 2 ms after a kernel
>> ntpd is slow, but not that slow. Since for greater than 128ms offset it
>> does a step, and since it fixes things by about 1/2 per hour, half a day
>> is more like it to get it down to microsecond, not millisecond ranges.
> Indeed, the NTPD was restarted on most of my PCs today (update from
> 4.2.7p258 to 4.2.7p259) and you can see the transients here:
> A fraction of an hour, not days. I don't have a plot coming up from cold,
> though. That may take a few hours for ultimate stability.
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.
More information about the questions