[ntp:questions] very slow convergence of ntp to correct time.
Richard B. Gilbert
rgilbert88 at comcast.net
Sat Jan 19 22:37:45 UTC 2008
> Unruh <unruh-spam at physics.ubc.ca> writes:
>>In trying to figure out whether it is chrony or the machine which is
>>causing the oscillations in the rate on my systems, I decided to switch one
>>to ntp. That system was withing 10usec of the "correct" time ( ie the time
>>as desgnated by a GPS driven computer withing about 150usec roundtrip
>>network distance). ntp started up and the offset steadily climbed until it
>>was 60msec (not usec) offset. At that point finally ntp started to do
>>gradually brought the offset down. Now, three hours later it is still
>>14msec (1000 times worse than it started out as) offset and has settled
>>loopstats says that the timescale is now a 9 ( which I guess is 500 sec--
>>10 min) while the clock still sits there 14 msec away from the correct
>>time with little evidence of the offset decreasing.
>> While I can understand the desire to have
>>long integration constants, but surely the convergence to the correct time
>>( or rather say +- 10usec, not 10ms from correct time) should be a bit
>>faster than this.
>>Is there some problem in ntp?
> Just an update. ntp has now been running for 15 hrs, and the offsets are
> still in the few ms range (all positive). The frequency has converged but
> the offsets have not. ntp has gone to max time (level 10) for the querying,
> but the offsets are still over 100 times worse than I was getting with
> chrony. (Yes, I know, one suggestion is-- go back to chrony-- but the
> reason I am carrying out this test is to see if those rate oscillation I
> was seeing with chrony are eliminated with ntp, with comparable accuracy.)
> Since the client and server are only about 50usec apart (round trip time is
> about 120usec typically) ntp should be able to much better than 3-4ms
> control of the clock on the client I am seeing, since the server has typical offsets of
> 3 or 4 usec.
> I am also getting weird behaviour of the round trip time. Both machines are
> lightly loaded, so it is not a problem internal to the machines (client and
> server) and both are connected through a single Gigabit switch to each
> other. While the typical round trip time is .12 ms, overnight (network
> traffic low on a Fri night) I have gotten about 10 cases where the round
> trip time is 5-10ms (Ie, 40-80 times longer than typical.) I have long
> suspected that there is a problem in the switches but other suggestions are
> I would assume that ntp is giving these samples with long round trip very low weight, or even
> eliminating them.
Could you take a moment to explain what "chrony" is/does? One gathers
that it's some sort of a clock managing/correcting program but one I've
never heard of before!
Did you have an existing "drift" file when you started ntpd? A drift
file that's far from the current drift value can mess things up! If the
drift file is stale, it's best to delete it.
Ntpd generally needs about thirty minutes to beat your clock into
submission. Once synchronized to a stable source it should stay
synchronized. Note that the "stable source" part is important! A
stable source is something like a GPS timing receiver either locally
connected or connected to a server nearby in net space. Ntpd tends to
"clock hop" among internet servers if that's all it has to work with;
since internet servers seldom agree with each other exactly (most likely
the network's fault) what you get is ntpd's best guess as to the correct
Posting your ntpq -p "banner" might tell us something useful. Just note
that ntpq -p is not much use until ntpd has been running for at least
More information about the questions