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

Terje Mathisen terje.mathisen at hda.hydro.com
Fri Feb 4 07:31:52 UTC 2005


Wolfgang S. Rupprecht wrote:

> Brad Knowles <brad at stop.mail-abuse.org> writes:
> 
>>	If you want to make that delay shorter, I guess you could
>>package Stratum 1 refclocks with every machine.
> 
> 
> I'd be waiting for minutes if I waited till ntpd decided it had a
> "good enough" estimate of the Motorola Oncore's time.  Ntpd *could*
> have its first time estimate accurate to well under 1ms in half a
> second on average.  The problem is, it won't tell you the time or step
> the system clock until it filters the crap out of the refclock signal.
> 
> Ntpd has a hard act to follow.  The old ntpdate program was a near
> ideal solution from the perspective of booting.  It did its job
> quickly and got off the pot.

Except the few times when it messed up horribly:

I had one of the my GPS-based stratum 1 server go bad on me a few years 
ago, and found out the hard way that _one_ critical server in our 
infrastructure had been configured to use this particular server as the 
only ntpdate reference:

It was rebooted during the time interval before the failing ntp/gps 
server was located and turned off, with the result that this unix db 
machine came up with a wildly wrong date.

After ntpdate had run, ntpd was started, but even though it had been 
configured with four server lines, only the temporarily broken server 
used by ntpdate was sufficiently close to be accepted, all the others 
were deemed falsetickers.

A perfect ntpdate replacement needs to locate all or most of all the 
configured servers, and run at least a couple of packets to each server, 
and wait until a plurality have agreed on what the time is. This can be 
handled in an absolute minimum of about 3-5 seconds without polling each 
server more often than every two seconds.

If you configure fewer servers, then you'd need more packets to each 
server before a sufficient reach value could be achieved for the set of 
servers that agree.

The same goes in case of one or more falsetickers of course: They must 
be detected and filtered out, which requires more packets to all the 
servers than if they all agree.

Prof. Mills' latest tweak, allowing you to tune (i.e. reduce) the 
required quality of the initial time estimate could be used to balance 
your need for believable time vs time to achieve first sync.

Terje

-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list