[ntp:questions] Re: ntpd, boot time, and hot plugging
David L. Mills
mills at udel.edu
Fri Feb 4 22:24:43 UTC 2005
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
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
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
>>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