[ntp:questions] Re: Time mysteriously advancing with FreeBSD 5.3 and ntpd 4.2.0-a

Richard B. Gilbert rgilbert88 at comcast.net
Sat Jan 1 15:58:11 UTC 2005

Mxsmanic wrote:

>Richard B. Gilbert writes:
>>Depennding on the quality of your servers and your network connections 
>>to those servers, ntpd may need from twelve to thirty-six hours to 
>>achieve tight synchronization.
>Is this after every boot, or only after ntpd is first installed?
>The time does seem to have stabilized.  For a while it was as much as
>10-15 seconds off, but for the past few days (almost 72 hours now), it
>has been right on the mark.  I suppose ntpd has to train itself to get
>used to new servers and a new local hardware clock, no?
That's after every "cold start"; e.g. where you power down long enough 
for the machine to cool off.   If you configure a drift file, and you 
should, the first time will be the worst.  The drift file provides a 
reasonable starting value for the correction to your clock frequency.  
That value is specific to the particular machine and environment.

>>If the quality of the servers etc, is 
>>poor enough you may never achive tight syncronization.
>The daemon seems to change its mind a lot about which server to use for
>its reference, but it does seem to pick the same two or three servers
The daemon will "clock hop"!   It evaluates the quality of all your 
configured servers every time it polls them.  If you graph your 
clockstats and peerstats, you may find it enlightening.  If you could 
configure a statistically significant number of servers; say 200, I 
believe that you would find that they form a normal distribution around 
the correct time.   If your round trip delays are not symmetrical, that 
distribution will be skewed with respect to UTC.  The standard deviation 
of the distribution will vary with the time of day; I find that the 
daylight hours are the worst.

If you are able to compare network servers to a stable clock source such 
as a GPS receiver or a rubidium or cesium clock, you will find that the 
network servers oscillate around the correct time. The best stay very 
close.  Some have been known to wander pretty far.   I have a server 
that's technically stratum one, because it's synched to WWV, that has 
been off by more than 400 milliseconds with respect to GPS.

A well known server in Delaware deviates +/- 30 milliseconds from GPS 
over the course of a day!  I have seen a few that are worse.  The local 
clocks of the servers I use regularly may be far better than what I see 
but the end result as delivered here is what counts

>>I normally see 
>>offsets in the 100us to 1ms range from my GPS reference clock and 
>>offsets in the 5 to to 20ms range for the best of the network servers I 
>This is something I also don't understand very well: If you have a very
>accurate local reference clock, what's the utility of querying distant
>NTP servers?  Is it just a sanity check, or what?  Won't the local clock
>_always_ be the final reference used by NTP?

If you have a reference clock that  always works correctly, there's no 
point in using another.  If you find or invent such, please let us know; 
the market for such would be huge.   With a solid signal from four or 
more satellites, a good quality GPS clock should be within, say, 100 
nanoseconds of UTC.   But the distribution of satellites in the sky is 
somewhat less than uniform.  I find that I have solid reception for 
eight or nine hours per day.  A better antenna or a better location 
might improve matters but I have not yet been able to do it.

The vagaries of HF propagation can make an HF radio clock such as WWV, 
WWVH, CHU, JJY, etc, either unreliable or unusable at certain hours of 
the day.

So you configure network servers for backup and a sanity check.  If your 
reference clock isn't working, your stratum increases from 1 to 2 or 3 
but you are still synchronized and still reasonable correct.


More information about the questions mailing list