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

David L. Mills mills at udel.edu
Fri Feb 4 22:24:43 UTC 2005


Steve,

Darn, things get so dang complicated. What you suggest would work fine 
if you don't mix with other options, like jimmy the step threshold or 
set the -x option. With these it is possible the first ntpd could exit 
leaving a whopping offset error and without measuring and correcting the 
frequency.

Your suggestion about using a larger number of servers initially and a 
smaller number later is exactly what ntpd does now; however, there is 
the additional overhead for polling servers that don't make the final 
cut. To sustain stability beyond a clockhop, the discarded servers have 
to be polled at not more than the system poll interval, which 
ordinarilly ramps up to 1024 s. This would ordinarily not be considered 
a burden on today's infrastructure; but, if it is, the manycast scheme 
could be extended as an optional feature for other modes.

In manycast mode a client uses a multicast beacon and expanding-ring 
search to solicit potential servers in the nearby neighborhood. For each 
response the client mobilizes a unicast association and continues in the 
normal way. Just as in the other modes, the falsetickers and outliers 
are pruned, but in manycast mode the associations for these critters are 
demobilized. Every once in a long while the client beacons again and 
repeats the process.

Manycast mode has been implemented, test and in regular operation here. 
The intent, howver, is to extend it to use the pool servers as discovery 
means. However, this requires an agile asynchronous DNS resolver, which 
is not yet a feature. If somebody will do that, I'll do the rest. As 
bonus, that would dramatically reduce the ugly weeds in the initial 
startup process.

Dave

Steve Kostecke wrote:

> On 2005-02-04, Tom Smith <smith at cag.lkg.hp.com> wrote:
> 
> 
>>So you're suggesting that the requirements for initial acquisition of
>>an estimated time necessary to get ntpd off the grounbd are different
>>from the requirements for long-term maintenance of an accurate and
>>stable time.
>>
>>I certainly agree.
> 
> 
> One way to handle this is to run 'ntpd -gq -c /etc/ntp.boot' followed by
> a normal ntpd start-up.
> 
> /etc/ntp.boot would contain a list of servers (perhaps fewer than in
> /etc/ntp.conf) _and_ the new tuning knob to speed up acquisition.
> 



More information about the questions mailing list