[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