[ntp:questions] Re: ntpd, boot time, and hot plugging
Richard B. Gilbert
rgilbert88 at comcast.net
Fri Feb 4 21:59:10 UTC 2005
Tom Smith wrote:
> Brad Knowles wrote:
>
>> At 4:21 AM +0000 2005-02-04, Tom Smith wrote:
>>
>>> # time ntpd -gq [13 servers in ntp.conf]
>>> ntpd: time slew -0.000373s
>>>
>>> real 1m43.03s
>>> user 0m0.10s
>>> sys 0m0.60s
>>
>>
>>
>> Yes, but what does that ntp.conf look like? Are you using
>> iburst? Any authentication? Manually setting minpoll and/or
>> maxpoll? Did you have a good drift file to start with?
>>
>> You need to provide some more specifics before you can make an
>> attempt to compare this to ntpdate.
>>
>>> # time ntpdate -b [three selected servers]
>>> 3 Feb 22:44:45 ntpdate[186032]: step time server [IP address]
>>> offset -0.000157 sec
>>
>>
>>
>> Not comparable. You need to include all thirteen servers before
>> this could potentially be considered comparable.
>>
>
> As you wish...
>
> # cat /etc/ntp.drift
> -2.653
>
> # ntpq -p
> remote refid st t when poll reach delay
> offset jitter
> ==============================================================================
>
> LOCAL(1) LOCAL(1) 5 l 41 64 377 0.000
> 0.000 0.004
> [IP.255] 0.0.0.0 16 u - 64 0 0.000 0.000
> 4000.00
> -[name] .TRUE. 1 u 468 1024 377 12.741
> -0.950 0.092
> -[name] .WWVB. 1 u 470 1024 377 1.388
> 1.015 1.216
> -[name] [name] 2 u 135 256 337 0.004
> -0.490 0.440
> -[name] .GPS. 1 u 997 1024 377 88.936
> 0.153 1.854
> +[name] .GPS. 1 u 603 1024 377 88.146
> 0.546 0.119
> *[name] .GPS. 1 u 764 1024 377 88.311
> 0.605 1.387
> -[name] .GPS. 1 u 783 1024 377 73.649
> 0.766 12.499
> #[name] [name] 2 u 652 1024 377 83.509
> -0.371 0.725
> -[name] .GPS. 1 u 720 1024 377 32.581
> 1.203 0.082
> +[name] .GPS. 1 u 744 1024 377 105.719
> 0.604 1.952
> -[name] .GPS. 1 u 686 1024 377 92.301
> 3.050 0.447
> #[name] [name] 2 u 339 1024 176 0.796
> -1.401 0.245
> #[name] [name] 2 u 520 1024 376 10.376
> -2.257 0.814
> [name] 0.0.0.0 16 u - 1024 0 0.000 0.000
> 4000.00
>
> # time ntpd -gq [above 14 servers/peers with iburst, plus local. No
> authentication.
> Default min/max poll. All appropriate for long-term time
> maintenance.]
> ntpd: time slew 0.000527s
>
> real 0m45.00s
> user 0m0.11s
> sys 0m0.55s
>
> [Note that ntpd -gq isn't really done when it unblocks. It has only
> initiated a slew. But we'll let that pass becasuse the time is
> already way more than "good enough".]
>
> # ntpdate -b [same set of servers and peers, except no local clock. Way
> overconfigured for one-time "good enough" acquisition at
> boot.]
> 4 Feb 13:21:32 ntpdate[201766]: step time server [IP] offset 0.000647
> sec
>
> real 0m6.73s
> user 0m0.00s
> sys 0m0.00s
>
> ________________________________________________________________________
> Tom Smith smith at alum.mit.edu,smith at cag.lkg.hp.com
> Hewlett-Packard Company Tel: +1 (603) 884-6329
> 110 Spit Brook Road ZKO1-3/H42 FAX: +1 (603) 884-6484
> Nashua, New Hampshire 03062-2698, USA Mobile: +1 978 397 3411
If you omit the "q" option, ntpd will simply set the clock and keep
running! If the error is greater than 128 milliseconds it will step the
clock, otherwise it will slew the clock. In either case you are up and
running with a clock error of less than 128 millieconds. Is this not
good enough? If not, what is your requirement for accuracy?
More information about the questions
mailing list