[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 14:51:14 UTC 2004


Mxsmanic wrote:

>Richard B. Gilbert writes:
>
>  
>
>>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!
>>    
>>
>
>I'm in Europe, so delays of 100+ ms to the US are unfortunately typical.
>
>  
>
>>Ideally, the round trip delays would be symmetrical but the world
>>is seldom ideal.
>>    
>>
>
>Oddly enough, my impression is that delays to US servers are longer, but
>more consistent over time, at least over intermediate periods (hours).
>
>  
>
>>The servers with the lowest delays appear to be in Denmark which is a 
>>little strange if you are in the USA.
>>    
>>
>
>They're in Germany.  I figured German servers would be trustworthy.
>
>  
>
>>If you are located in or near Denmark, why are you using all
>>those servers located in the USA?
>>    
>>
>
>Because I've had a hard time finding trustworthy, public servers in
>Europe.
>
>  
>
>>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.
>>    
>>
>
>I've tried servers right here in my metropolitan area a few times, but
>they seemed to be more random in their response times and delays than
>faraway servers.
>
>  
>
>>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.
>>    
>>
>
>I set the -g option but the daemon had not been running long when I ran
>those numbers.  This is what they look like now, after many hours:
>
> # ntpq -p
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  tick.usno.navy. .USNO.           1 u    9 1024   17  147.285  -87.954  23.298
> +time-a.nist.gov .ACTS.           1 u    4   64  377  109.996  -103.77   3.370
> *time-b.nist.gov .ACTS.           1 u   12   64  377  110.707  -108.44   1.700
> -tock.usno.navy. .USNO.           1 u   49   64  277  147.667  -112.26 157.350
> -time-nw.nist.go .ACTS.           1 u   27   64  377  193.522  -110.77   3.410
>  time-A.timefreq .STEP.          16 u    - 1024    0    0.000    0.000 4000.00
>  time-A.timefreq .STEP.          16 u    - 1024    0    0.000    0.000 4000.00
> -time-A.timefreq .ACTS.           1 u    5   64  377  177.909  -122.46   3.375
> +ntp1.ptb.de     .PTB.            1 u    2   64  377   54.645  -103.43   2.509
> +ntp2.ptb.de     .PTB.            1 u   59   64  377   53.357  -105.80  13.954
>  pix.mxsmanic.co 10.0.0.80        3 u   43  256  376    0.002  -39.003   1.586
> # 
>
>Looks like ntpd is watching time-b.nist.gov now--I notice that it's the
>server with the lowest jitter.  Is that a good thing?  What do each of
>these numbers represent?  I can't seem to find clear documentation on
>understanding which figures are key to accuracy.
>  
>
Try RFC1305 <www.eecis.udel.edu/%7Emills/database/rfc/rfc1305/>
The math is a little to hairy for me but it's all there.

>  
>
>>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.
>>    
>>
>
>OK, but where can I look to discover the names of public servers I can
>use?
>  
>

Try http://ntp.isc.org/bin/view/Servers/StratumTwoTimeServers
for a list.

>The weird thing is that I had very good sync with the same configuration
>previously, in FreeBSD 4.2.  What has changed?  Or is it just a matter
>of building up drift information again (the motherboard and hence the
>system clock hardware has changed, and I erased the old ntp.drift file
>since I figured ntpd would need to collect fresh data).
>
>Right now the clock is perceptibly fast (about .5 second).  Would it
>still be that far off normally after eight hours of operation?
>
>  
>
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.  If the quality of the servers etc, is 
poor enough you may never achive tight syncronization.  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 
use.   These network servers are all within 300 miles of my site and 
most are within 150 miles.




More information about the questions mailing list