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