[ntp:questions] Speed of ntp convergence

Unruh unruh-spam at physics.ubc.ca
Sat Nov 1 21:12:44 UTC 2008


"David J Taylor" <david-taylor at blueyonder.neither-this-part.nor-this-bit.co.uk> writes:

>Unruh wrote:
>[]
>> An hour later, it was still 7ms off, another hour, 2.6ms and another
>> hour
>> later, still 1.2 ms off. Ie, only after about 6 hours was it within a
>> ms of
>> the correct time. Now, usually this PPS controls the time to within
>> about 2us (not ms, usec) but it is apparently going to take over 10
>> hours to get
>> there. That is of course completely rediculous.

>There sounds to be something wrong with your system.

Nope, it is not my "ssytem" if by that you mean my computer. The
convergence is a beautiful exponential convergence with a time scale of 1
hour almost exactly. That is not hardware. That is the software ntp
protocol.


>As a comparison, I have a very old Pentium 133 system here running FreeBSD 
>with local GPS PPS and some other Internet-based stratum 2/3 servers 
>(probably NTP pool and a fixed name).  I'm sure it's well within a few 
>minutes for it to reach it's full accuracy (tens of microseconds).  For 
>interest, I've just (0645 UTC) switched it off and on, and we will be able 
>to watch its recovery here (30 minute updates):

Try switching it off, changing the value int he drift file by say 50PPM and
then switching it on again, and see how long it takes to recover from that.

Note, if you are running gps, why have a poll level 6? The recommendation
for ref- clocks is poll level 4?

>  http://www.satsignal.eu/mrtg/pixie_ntp.html

>Here it is about a minute after startup:

>ntpq -p pixie
>     remote           refid      st t when poll reach   delay   offset 
>jitter
>==============================================================================
>+calx.pulsewidth 193.120.10.3     2 u   62   64    1   22.272    1.700 
>0.743
>+admin.islay.bit 192.33.96.102    2 u   62   64    1   21.131    0.921 
>1.112
>+dnscache-london 128.250.33.242   2 u   62   64    1   22.845    3.299 
>0.666
> 88-96-233-89.ds .PPS.            1 u   14  128    7   63.431    0.044 
>2.789
>*utserv.mcc.ac.u 193.62.22.98     2 u   64   64    1   26.494    4.312 
>0.829
> GPS_NMEA(1)     .PPS.            0 l   12   64    3    0.000   -0.137 
>1.654

>.. and a few minutes later ...

>ntpq -p pixie
>     remote           refid      st t when poll reach   delay   offset 
>jitter
>==============================================================================
>+calx.pulsewidth 193.120.10.3     2 u   54   64   37   22.348    2.946 
>0.877
>+admin.islay.bit 192.33.96.102    2 u   53   64   37   20.496    1.862 
>1.057
>+dnscache-london 128.250.33.242   2 u   57   64   37   23.090    3.809 
>0.662
> 88-96-233-89.ds .PPS.            1 u  134  256   17   63.431    0.044 
>2.007
>+utserv.mcc.ac.u 193.62.22.98     2 u   53   64   37   25.564    5.371 
>0.868
>*GPS_NMEA(1)     .PPS.            0 l    3   64   77    0.000   -0.001 
>0.803

>It's using the out-of-the-box NTP code, and probably a rather old version 
>of NTP.

>  version="ntpd 4.2.0-a Sun May  8 06:01:21 UTC 2005 (1)"

>It's a very simple system, described here:
>  http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm

And I am using 4.2.4p4



>Cheers,
>David 




More information about the questions mailing list