[ntp:questions] oscillations in ntp clock synchronization
unruh-spam at physics.ubc.ca
Fri Jan 18 04:03:19 UTC 2008
ibuprofin at painkiller.example.tld (Moe Trin) writes:
>On Thu, 17 Jan 2008, in the Usenet newsgroup comp.protocols.time.ntp, in article
><kbBjj.34002$fj2.20407 at edtnps82>, Unruh wrote:
>>Yup ordinary computers. They are between 0-100PPM out-- across about
>>8 of them. But the cyclic variation is strange.
>A 100 ppm error due to thermal problems ALONE should be unusual, as
>that would be suggestive of the device temperature changing a very
>large amount (multiple tens of degrees C) or an extremely crappy
>crystal cut (I don't think anyone is using X-Cut crystals any more).
>But are you discussing the variation of an individual unit changing
>up to 100 ppm, or that two (or more) units differ by up to 100 ppm.
Sorry, no, that 0-100 is the range of rates of the various clocks, not the
changes due to temp. I have some that have a 10PPM sudden change but I do
not know why-- ie I do not know if it is thermal or some othr reason. But
superimposed on that change, there is this oscillation in the rate.
The oscillation in the offset is of the order of 10usec-- corrected by
>>What is strange is the about 1.5 hour timescale. There is nothing I
>>know of in any of the rooms that has that time scale.
>Are all units in a single room showing similar time/rate/direction?
>Room temperature isn't the only thing that can cause problems - it
>could be load, vibration, and/or power supply voltage just as well.
>But an oscillation with a period that long still suggests a wrong
>set of constants in a feedback loop, especially in the absence of
>external changes of a similar nature. If the period/span remains the
>same 24/7 - I'd be looking at the filter a lot closer.
the period seems to remain roughly the same 24/7, although sometimes the
oscialltion will just cease.
>>thermometers (onboard) to better than 1C?
>If you mean something like "lm_sensors" or reading the "Thermal
>Reference Byte" in some Intel processors, no, I don't think so, and
>I'd be wary of the data anyway. The "Thermal Reference Byte" is
>subject to _calibration_ errors, (zero and scale), while the
>"lm_sensors" data is subject to the sensor error as well as the
>errors in the circuit that is converting the voltage to a digital
>representation (I've discussed this in the past - recall that this
>is commodity gear, accurate to 5-10 percent AT BEST, never calibrated,
>and tested by half-starved chimpanzees to a "yes it's working/no it's
Sure, but it is the changes that are of interest. Ie I do not care if it is
45.1 to 45.7 or really 39.6 to 40.2 . It is the fluctuation and the
correlation of the fluctuation with the rate that I am interested in, to
see if it really is the temp which is causing the oscillations.
>If you wanted to construct something - a thermistor, a couple of
>precision resistors, a supply reference, and a decent op-amp AND THEN
>CALIBRATING the darn thing, then 1/20th degree should be obtainable
>but I wouldn't look to commodity products for this.
>>I can see some major variations in teh temp causing rate changes in
>>the clock, but the small oscillations, if they are caused by thermal
>>effects, are much smaller temp variations than are visible with a 1C
>Accuracy, or resolution, or both? In one case up-thread, you talk
>about a 2-3 usec amplitude, and that would be trivial - Assume a 100
That 2-3usec is on an ntp controlled system linked to a GPS PPS source.
Ie, this does not show the rate changes, just the offset after the ssytem
has been corrected by the PPS.
>ppm over 0-70C, then a 1C change _could_ produce a 1ppm error, and
>that puts you out 2-3 usec in 2-3 seconds. (I'm talking time for the
>drift, not the response time of the change in temperature to the actual
>change in frequency.)
The ntp is on a 16 sec time scale of reading update ( shm refclock).
> Old guy
More information about the questions