[ntp:questions] Re: NTP, Mac OS X & Cisco 837

Richard B. Gilbert rgilbert88 at comcast.net
Sat Apr 16 03:01:58 UTC 2005


viz wrote:

>
>
>On 15/4/05 10:02 PM, in article WPudnYDpD-ryMMLfRVn-pw at comcast.com, "Richard
>B. Gilbert" <rgilbert88 at comcast.net> wrote:
>
>
>
>>>root# ntpq -p
>>>    remote           refid      st t when poll reach   delay   offset
>>>jitter
>>>============================================================================
>>>==
>>>bm2.asia.apple. a17-106-100-13.  2 u    -   64    3  129.661  -46.525
>>>31.619
>>>mel001.pacific. murgon.cs.mu.oz  2 u   30   64    3   97.368  -52.562
>>>64.635
>>>marvin.ci.com.a .PPS.            1 u   25   64    3   27.514  -35.673
>>>33.683
>>>murgon.cs.mu.oz .GPS.            1 u   21   64    3   35.508  -38.358
>>>31.629
>>>*ntp1.cs.mu.oz.a .GPS.            1 u   61   64    1   38.561  -15.461
>>>4.094
>>>+kermit.goldweb. yarrina.connect  3 u    2   64    1   25.106  -46.715
>>>4.528
>>>+ntp1.tpgi.com.a ntp1.tip.csiro.  2 u    2   64    3   24.444  -87.599
>>>26.148
>>>wlmla.solnetsol amp-gw.compass.  3 u   62   64    1   55.388  -15.074
>>>5.672
>>>
>>>Looks like it is working! :)
>>>
>>>Dunno why I had the problems before with only the four servers being
>>>selected; however a reboot fixed that!
>>>
>>>Thanks to all those who helped, in particular Brad. :)
>>>
>>>/viz
>>>
>>> 
>>>
>>>
>>I'd suggest dropping:
>>
>>bm2.asia.apple. . ., and
>>mel001.pacific. . . from your list.
>>
>>The reported delays of 129ms and 97ms are a little too high for comfort!  The
>>six servers you would have left should be more than sufficient.
>>
>>If you haven't yet added the iburst keyword to your server statements, doing
>>so will speed up your initialization of each association.  It causes the first
>>eight requests to be sent at intervals of two seconds instead of the normal
>>sixty-four.  After the first five replies from each server have been received,
>>ntpd has sufficient information to begin setting your clock.
>>
>
>This is what I get 9 hours later:
>
>ntpq -p
>     remote           refid      st t when poll reach   delay   offset
>jitter
>============================================================================
>==
> bm2.asia.apple. time2.euro.appl  2 u  229 1024  377  176.709  933.761
>944.448
>+mel001.pacific. murgon.cs.mu.oz  2 u  991 1024  377   35.108  912.078
>924.795
>+marvin.ci.com.a .PPS.            1 u  995 1024  337   30.887  915.093
>928.658
>+murgon.cs.mu.oz .GPS.            1 u  228 1024  377   33.509  909.139
>923.733
>*ntp1.cs.mu.oz.a .GPS.            1 u  790 1024  377   36.546  912.455
>924.651
>+kermit.goldweb. yarrina.connect  3 u  274 1024  377   31.445  911.856
>925.497
> ntp1.tpgi.com.a murgon.cs.mu.oz  2 u  267 1024  377   23.941  858.292
>930.568
> wlmla.solnetsol gen2.ihug.co.nz  3 u  275 1024  377   57.048  910.245
>922.389
>
>me1001 has come back into the fold, whereas apple.asia needs to take some
>mad pills... Might leave it there for fun ;)
>
>/viz
>
>
Something is still very wrong!

Was your system that far off when you started ntpd?  Or did it get that 
way over the next ten hours?  You should not have offsets of 900+ 
milliseconds if everything is working right!  I expect, and get, offsets 
of less than twenty milliseconds using only network servers.   When my 
GPS is working, I expect, and get, offsets of less than 100 
microseconds!  The numbers for jitter are also among the highest I've 
ever seen!!!

Also, with offsets that large, I don't believe that ntpd should be 
polling at such a long interval; 1024 seconds is for when your frequency 
and phase errors are very small.  With offsets as large as you have, 
ntpd should be polling every 64 seconds.

Are you running the version of ntpd that shipped with your O/S or one 
that your built from source?  What version is it?

I'd say you have: a hardware problem with your clock, a software problem 
with the version of ntpd you are running, or a configuration problem!



More information about the questions mailing list