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

David L. Mills mills at udel.edu
Fri Feb 4 21:53:31 UTC 2005


Alain,

In the ntpd documentation for the -g option:

Normally, ntpd exits with a message to the system log if the offset 
exceeds the panic threshold, which is 1000 s by default. This option 
allows the time to be set to any value without restriction; however, 
this can happen only once. If the threshold is exceeded after that, ntpd 
will exit with a message to the system log. This option can be used with 
the -q and -x options. See the tinker command for other options.

Dave

Alain wrote:
> Answers to several messages:
> 
> ----------
> David L. Mills escreveu:
> 
>  > Alain,
>  > No, don't use ntpdate at all. Use ntpd -g with the tos maxdist 16 if 
> you want instant synchronization. There are several combinations of the 
> tos commmand that could be used to modify behavior, such as the minsane 
> and minclocks arguments. TO determine what they do you have to 
> understand the icky algorithms; however, after studying the briefings at 
> the project page and understanding how the algorithms work, it should be 
> fairly obvious.
> 
> 
> The problem is that -g has a limit of 1000 seconds. My worst case 
> scenario (I have seen it a lot) includes dead bateries and initial times 
> of 1/1/1980. Second worst is UCT missconfiguration, many hours off. And 
> not to forguet Summer Daylight savings time that is more than 1000s.
> 
> Even worse is that it exits ntpd. This requires another deamon to check 
> if it happened :(
> 
> If ntpdate disapears, there should be *some* way of handling this.
> 
> -----------
> Tom Smith escreveu:
>  >> So, if I manage to set the initial time within a good aproximation od
>  >> "real" time using ntpdate using 5 servers as explained earlyer, would
>  >> you recomend to delete the drift file and let it start all over again?
>  >
>  > If you do that, there should be no need to clean out the
>  > characteristic drift that was so carefully computed over a long
>  > period of time. Cleaning out the drift file is a drastic measure
>  > required only if you do NOT pre-set the clock before starting ntpd
>  > and you end up, as a result, with a bogus re-calculated drift rate.
> 
> So I understand that testing drift and deleting it only if it is 
> +-500.00 is the more generic aproach for for all situations?
> 
> ----------
> Terje Mathisen escreveu:
>  > 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.
> 
> Behind this is a missconfigured and forgotten configuration. I believe 
> the script to use many servers that are *in* ntp.conf would prvent that, 
> specialy that these servers will probably be checked periodicaly with 
> ntpq -p.
> 
> -----------
> I believe than that for a more general situation:
> 1) ntpdate with many servers from ntp.conf (5 is reasonable)
> 2) check if drift is +-500.000, if so delete it.
> 3) Start ntpd
> 4) periodicaly check external (and internal) servers to see if a 
> reasonable number of them are still there.
> 
> Alain



More information about the questions mailing list