In article <[EMAIL PROTECTED]>, Steve Kostecke <[EMAIL PROTECTED]> wrote: > On 2007-02-08, Donald Murray, P.Eng. <[EMAIL PROTECTED]> wrote:
> > How quickly can an isolated ntp server respond to 'ntpdate' queries > > after the server starts? Immediately, but ntpdate will ignore the replies. > Changing the clock while ntpd is running is not a good idea. ntpd will > attempt to "correct" the observed change in the clock. Like only using kill -9 as a last resort, this is good general advice which is often ignored, for convenience. However, in this specific case, ntpd will observe no change in the time as it will be comparing the altered time against the altered time. > ntpd should be stopped, the clock adjusted, and then ntpd can be > started. (The best way of adjusting a hot local clock server is to fudge the frequency and wait until the time crosses the correct time, but this is unlikely to be acceptable in this usage, because of the skill and man time required.) > > authenticate no > Disabling authentication makes it possible for anyone with ntpdc to > tinker remotely with this ntpd. I'd need to check, but I don't think this is true. I think it only disables it with regards to peer time servers, not with regard to control messages. > We're running 4.1.0 ntpd on 2.4.22 kernels. Since there are thousands 4.1.0 is a bit old. I'm not sure if it supports iburst. > > of remote sites, upgrading ntpd would be prohibitively expensive. That makes life very difficult, as you almost certainly need to hack the ntpd code to special case the local clock server, when it is the only configured server. > When CLIENT's PPP link comes up we run the deprecated 'ntpdate -b > SERVER'. This works fine as long as ntpd on SERVER has been running > Again, you should not change the clock while ntpd is running. When the > ppp link comes up you should stop ntpd, run ntpdate, and then start > ntpd. You might just get away with it if you do it so fast that ntpd hasn't had a chance to poll the server itself. But it is certainly not a good idea to do it. In this case, assuming that you are using the kernel clock discipline code, you should start ntpd on ip-up and stop it on ip-down. > Is there anything I can do to SERVER's ntp config to encourage it to > respond to remote ntpdate queries more quickly on startup? I think you should be considering whether you should be using ntpd at all. If the server is being set by eyeball and wristwatch and this is a relatively frequent event on many sites, the application obviously doesn't require particularly accurate time or guaranteed monotonicity. (In controlled environments, and using a radio controlled wristwatch, 100ms is achievable, but I suspect we are talking more like a minute here.) Using netdate instead, will give you time transfer with a 1 second resolution as soon as inetd has started on the server - you will probably need to enable the relevant service, as modern practice is to block everything by default. The main problem will be that you probably need a faster poll until you get the first successful return, but a slow one thereafter, to avoid the time jumping around too often. You can also improve things by calibrating the drift value on the machines. If you still want to run ntpd, you can set it in the driftfile, but with Linux and the kernel discipline, you can use ntptime to load it into the kernel, without ever running ntpd. This will reduce the number of manual adjustments needed. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
