[ntp:questions] Re: ntpd, boot time, and hot plugging

Richard B. Gilbert rgilbert88 at comcast.net
Sat Feb 5 01:55:55 UTC 2005


Per Hedeland wrote:

>In article <cu0tn7$jmh$1 at dewey.udel.edu> "David L. Mills"
><mills at udel.edu> writes:
>  
>
>>Well, I found the step routine call; however, that code has grown so 
>>weedy with intricate evil little OS-dependencies that I find it 
>>unreadable. I haven't touched the ntpdate code since it first appeared 
>>probably fifteen years ago. So far as I can see, if somebody opts out 
>>the step correction, ntpdate can leave a big offset for later ntpd to 
>>chew on.
>>    
>>
>
>Yes, and along these lines are the reasons for dropping ntpdate that you
>have given in the past:
>
>a) It's hideously complex
>b) It does something that is similar to / a subset of what ntpd does (or
>   rather what it did many years ago), but not the same, which together
>   with a) makes it a pain to maintain
>c) It's feature set gives the impression that it might be reasonable to
>   use *instead* of ntpd (e.g. running hourly from cron) - there's no
>   point having the slew modes otherwise
>d) If widely used as in c), it's quite unfriendly to servers, when
>   gazillions of boxes send their 4 packets * N servers exactly on the
>   hour.
>
>FWIW, I find them perfectly valid - I'm just still not quite happy with
>the replacement.:-)
>
>If your latest ntpd tweak knobs can really achieve the low-quality-but-
>really-quick time setting that ntpdate provides, *and* the combination
>of knob settings needed for that is codified into another ntpd option
>(--impatient maybe?:-), I think ntpdate can finally be laid to rest.
>Requiring a separate config file just for this boot-time setting, with
>parameters and values that are even more esoteric to the average user,
>is really a show stopper IMHO.
>
>--Per Hedeland
>per at hedeland.org
>  
>
I think maybe what people are looking for, that ntpdate seems to do and 
ntpd does not, is:
1.  Get the time accurate to within  X seconds quickly.
2.  Set that time quickly.  The presumption here is that we are in a 
state where it's OK to step the clock; e.g. we are booting and nothing 
has started yet that will be upset by a change in time.  Slewing the 
clock to correct an offset of, say, 127 milliseconds, to within, say, 5 
milliseconds,  will take about 250 seconds and that is unacceptable when 
we need to be within 5 milliseconds of the correct time as quickly as 
possible.

The user may wish to specify the required accuracy, knowing that there 
is a trade off with elapsed time to achieve that accuracy.  How good 
"good enough" must be will vary.   Someone recording the time workers 
started work and the time they stopped may be satisfied with plus/minus 
one minute but it's 8:00AM local time and he needs it right now!  
Someone else might really need plus/minus ten microseconds and be 
willing and able to wait two or three hours to get it.

NTP may not be the right tool to meet some requirements but I think it 
should be possible to satisfy a lot of people with something that has 
capabilities similar to what I've outlined.




More information about the questions mailing list