[ntp:questions] Re: drifting on crystal

Richard B. Gilbert rgilbert88 at comcast.net
Thu Jan 13 01:58:22 UTC 2005


David Monniaux wrote:

> We have a scientific experiment in a remote location abroad where good 
> timekeeping is important. This experiment is monitored by a computer 
> 1) connected to the Internet using a DSL line (which goes down for 
> periods at times) 2) has a GPS receiver (which has problems of its own).
>
> When we are unlucky, the GPS has its "issues" within the same period 
> that DSL has its problems, and thus the computer becomes 
> unsynchronized with respect to precision clocks.
>
> I now wonder about the timekeeping in those bad periods. Questions:
>
> 1) While ntp works well, it can presumably have an idea of the amount 
> by which the system clock tends to drift (say, "the system clock is 
> 10^-6 slower than it should be") compared to reference clocks. Does 
> ntp use this information to compensate the clock when the reference 
> clocks are absent?
>
NTP does exactly that.  It measures both the frequency and phase (time) 
error of the local clock and attempts to correct both.  When you lose 
synchronization,  your local clock should be ticking at very close to 1 
second per second.  The problem is that, over time, the frequency of the 
crystal oscillator changes depending on the temperature, the supply 
voltage, the age of the crystal, the phases of the moon and the whims of 
the gods.  The local clock is not going to suddenly start gaining or 
losing thirty seconds per day;

You should have a "holdover" time of a few hours depending the the 
quality of the local clock and how tight your requirements are.

A slightly more serious problem is that, when you lose GPS, ntpd will 
try to synchronize your clock with your network servers which will 
almost certainly have an opinion of what time it is that differs from 
GPS by an mount that might range from one to ten milliseconds.  When GPS 
comes back on line ntpd will select it to synchronize with.   Your local 
clock is going to get jerked around every time ntpd selects a new 
synchronization source.

If you can live with ten or twenty milliseconds of error, you a probably 
doing the right thing.  If you need to be closer than that you should 
think about either fixing your problems with GPS, with DST, or both.  
You might also want to think about getting a better reference clock; 
cesium, rubidium or quartz frequency standards call all provide a 
somewhat better reference than the typical computer clock!   Cesium and 
rubidium standards are expensive, to say the least, but they provide 
superb accuracy and stability.  A well designed quartz frequency 
standard is capable of outperforming the hardware of a computer clock 
which, typically, represents an investment of about $2 US on the part of 
the computer manufacturer!!



More information about the questions mailing list