[ntp:questions] very slow convergence of ntp to correct time.

Unruh unruh-spam at physics.ubc.ca
Sat Jan 19 17:19:35 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
>something   and
>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
>down there. 
>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?
>ntp-4.2.0-31.2mdv2007.0



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
welcome.

I would assume that ntp is giving these samples with long round trip very low weight, or even
eliminating them.





More information about the questions mailing list