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

Richard B. Gilbert rgilbert88 at comcast.net
Tue Dec 28 03:19:53 UTC 2004


Mxsmanic wrote:

>Harlan Stenn writes:
>
>  
>
>>ntpd does not appear to be running.
>>    
>>
>
>I don't know why it wasn't running at that particular instant (I was
>fooling around with it), here is some more useful output:
>
>-----------
> # ntpq -p
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  ntp0.usno.navy. .USNO.           1 u  116  256   15  129.751  889.774  23.537
>  time-a.nist.gov .ACTS.           1 u  117  256   17  109.794  881.240   9.985
>  time-b.nist.gov .ACTS.           1 u  121  256   17  111.818  881.973   8.867
>  ntp1.usno.navy. .USNO.           1 u  379   64   40  221.691  843.580   0.002
>  time-nw.nist.go .ACTS.           1 u  124  256   17  193.774  884.099   7.535
>  time-A.timefreq .STEP.          16 u    -   64    0    0.000    0.000 4000.00
>  time-A.timefreq .STEP.          16 u    -   64    0    0.000    0.000 4000.00
> *time-A.timefreq .ACTS.           1 u   52  256   17  178.285  876.972   3.592
> +ntp1.ptb.de     .PTB.            1 u  128  256   17   54.647  891.017   3.229
> +ntp2.ptb.de     .PTB.            1 u  131  256   17   53.153  886.720   6.152
>  pix.mxsmanic.co 10.0.0.80        3 u   34   16  106    0.002  2251.31 789.891
> # 
>-----------
>
>  
>
>>See http://ntp.isc.org/Support/StartingNTP4 for more info.
>>    
>>
>
>Thanks, I'll take a look.
>
>  
>
You may have multiple problems but I think you have at least a problem 
with your network connection and/or choice of servers.  Delay figures 
of  over 100 milliseconds seem unreasonably high and leave a lot of 
uncertainty as to the correct time!  The only thing your ntp daemon can 
know about the time returned by a server is that the particular instant 
took place sometime between the time the request was sent and the time 
the reply was returned by the server.  If the time returned by the 
server was correct then the error is bounded by the delay time; e.g. it 
can't be any worse than the delay.   Ideally, the round trip delays 
would be symmetrical but the world is seldom ideal.

The servers with the lowest delays appear to be in Denmark which is a 
little strange if you are in the USA.  If you are located in or near 
Denmark, why are you using all those servers located in the USA?

The best servers will be those located closest to you in terms of 
delay.  The delay has many components: the physical distance the signal 
must travel, the number of hubs, switches, and routers the signal must 
pass through, how heavily the server is loaded, and how busy the network 
is.  Low numbers are good; high numbers are bad.

Next, your offsets are rather large.  This may be due to a number of 
things but the most likely two are that your ntp daemon has not been 
running for very long and that you did not set the clock before starting 
the daemon!   Use the -g option to start ntpd.  That will set the clock 
to the correct time.

Consider using stratum 2 servers.   Servers closer to you will provide 
much better synchronization.  The public stratum 1 servers are all 
extremely heavily loaded and cannot respond quickly which means that 
they cannot provide really good synchronization.




More information about the questions mailing list