[ntp:questions] Re: NTP broadcastclient update times?

Richard B. Gilbert rgilbert88 at comcast.net
Sat Oct 16 12:40:51 UTC 2004


W. D. wrote:

>Richard B. Gilbert wrote:
>  
>
>>W. D. wrote:
>>    
>>
>>>Harlan Stenn wrote:
>>>      
>>>
>>>>What is ...2.122?
>>>>        
>>>>
>>>FreeBSD / NTP time server
>>>      
>>>
>>>>How many machines is it sync'd to?
>>>>        
>>>>
>>>See below.
>>>
>>>      
>>>
>>>>What OS?
>>>>        
>>>>
>>>FreeBSD 4.9
>>>
>>>      
>>>
>>>>How about an ntpq -p against 2.122?
>>>>        
>>>>
>>>ntpq -p
>>>
>>>    remote           refid      st t when poll reach   delay   offset
>>>jitter
>>>==============================================================================
>>>-now.cis.okstate .PSC.            1 u  307 1024  377  226.292  -46.779
>>>5.793
>>>+navobs1.wustl.e .USNO.           1 u  993 1024  377  196.782  -29.412
>>>0.498
>>>*clock.xmission. .GPS.            1 u  914 1024  377  198.391  -31.001
>>>2.665
>>>+bonehed.lcs.mit .CDMA.           1 u  853 1024  377  194.764  -29.863
>>>0.985
>>>-clock.via.net   .GPS             1 u  303 1024  377  227.888  -47.328
>>>7.590
>>>-otc1.psu.edu    .WWV.            1 u  874 1024  377  199.845  -48.614
>>>3.173
>>>+timekeeper.isi. .GPS.            1 u   38 1024  377  231.352  -30.935
>>>528.528
>>>-ntp-cup.externa .GPS.            1 u  318 1024  377  233.925  -35.138
>>>7.098
>>>-time-B.timefreq .ACTS.           1 u   41 1024  377  231.446  -53.467
>>>280.040
>>>-clock.isc.org   clepsydra.dec.c  2 u  307 1024  377  227.118  -34.082
>>>7.550
>>>192.168.2.255   .BCST.          16 u    -   64    0    0.000    0.000
>>>4000.00
>>>
>>>
>>>      
>>>
>>There are two very notable things about this output.
>>
>>First, you have extremely high round trip delays to all the servers you
>>are using.  This can be caused by network congestion or by very long
>>network paths between your site and the servers.  
>>    
>>
>
>It is a very long path to (and through) my ISP.  Ping
>times average 140 ms at the 'front door' and 160 ms
>out the 'back door' to the rest of the Internet.
>By the way, I am so out in the boonies that I am 
>using dial-up.  They keep promising broadband, but
>aren't delivering.   That's probably the main reason for
>the long latency.  Also, these ping times are when
>I am not doing anything else on the 'Net.  They
>are going to be much more extreme when I'm using
>most of my 40 kbps for other tasks.
>
>  
>
>>In addition to
>>physical distance you must also consider the number of routers the
>>packets pass through; each one adds some delay in each direction.
>>Given a private wire from the east coast of the US to the west cost, the
>>speed of light delay should be less than thirty milliseconds 
>>    
>>
>
>Hmmm.  186,000 miles / second @ 3000 miles = 16.1 milliseconds
>

All right, that's thirty-two milliseconds for the round trip.  I was too 
lazy to do the arithmetic.

>
>  
>
>>so you are
>>seeing something more than simple distance.
>>
>>Finding servers closer to you in net space should substantially reduce
>>the delay and also the offsets.  
>>    
>>
>
>Yep.  I averaged 10 pings in choosing these servers. 
>
>
>  
>
>>Assuming that the servers have the
>>correct time in first place, the error/uncertainty is bounded by the delay.
>>With delays over 200 ms, ntp is essentially guessing what time it is.
>>    
>>
>
>But isn't NTP 'guessing' no matter what the delay is?  Isn't that the
>beauty of NTP?  No matter what the delay is, it will intelligently
>'guess' what the time *really* is, by factoring in that delay, right?
>
>  
>
Well, yes but it's an educated guess.  With delays on the order of 
twenty milliseconds you are within ten milliseconds of the correct 
time.  If the delay on the outbound trip is equal to the delay on the 
inbound trip you are generally a lot closer than ten milliseconds. 

>  
>
>>The second notable thing is that you are using numerous stratum 1
>>servers and, unless you are serving several hundred clients, you should
>>not be.  A few stratum two servers much closer (lower delay) should give
>>you much better performance and accuracy.
>>    
>>
>
>I'll research to see if I can cut down the delay times by 
>using these stratum 2 servers:
>http://ntp.isc.org/bin/view/Servers/StratumTwoTimeServers
>
>
>  
>
>>If  your network situation is such that there are no available servers
>>with delays of less than 25 milliseconds, you should probably consider a
>>hardware reference clock such as a GPS receiver.
>>    
>>
>
>Well, I was trying to keep this as simple as possible.  I called
>Synergy Systems (http://www.Synergy-GPS.com/) today and they
>said that I would need to spend at least $400.00 for a GPS
>setup.  I'd rather not spend that much money.
>
>If I don't go for the GPS option, I guess I'll just have to 
>live with these plus or minus 1 second adjustments then,
>correct?
>
>
>
>  
>
GPS is not the only type of hardware clock.  You can get a WWV receiver 
from Ramsey Electronics (in kit form).  If you are located where you can 
receive WWV's 10 MHz signal all the time you have the makings of your 
very own stratum 1 server.  I had to buy one to learn that the 10 MHz 
signal does not get to New Jersey at any hour  during the summer 
months.  On consulting a friend in Ham Radio, I learned that the 10 MHz 
signal is only usable in the winter months and then only at night.  You 
can have mine cheap!!

There is Jonathan Buzzards radioclock for VLF reception which could get 
you WWVB in the US and DCF or MSF in Europe.  This is a Do It Yourself 
solution; there isn't even a kit.

GPS is a very good solution if you have a clear view of the sky.   If 
your view is restricted, it's only going to work when you are getting 
good signals from at least four satellites.  When it does work, you get 
time that's supposed to be within 50ns of UTC.







More information about the questions mailing list