[ntp:questions] Using ntpdate -b SERVER shortly after SERVER boots
david at djwhome.demon.co.uk
Sat Feb 10 09:38:43 UTC 2007
In article <slrnesqan2.d1r.kostecke at stasis.kostecke.net>,
Steve Kostecke <kostecke at ntp.isc.org> wrote:
> On 2007-02-08, Donald Murray, P.Eng. <donaldm314 at gmail.com> 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
(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
> 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
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
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.
More information about the questions