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

[Alain]

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