[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)
martin.burnicki at meinberg.de
Tue Feb 10 09:03:22 UTC 2009
Harlan Stenn wrote:
>>>> In article <uck566-23p.ln1 at gateway.py.meinberg.de>, Martin Burnicki
>>>> <martin.burnicki at meinberg.de> writes:
> Harlan> Because ntpd also gets restarted, and there is a strong belief
> that Harlan> -g is bad for a restart and restarts will happen more often
> than Harlan> boots.
> Martin> Huh? I'm afraid I don't understand what you mean here.
> The general case is that -g should only be used at startup, when time can
> be stepped.
> If ntpd is restarted, it is Bad for the time to be stepped backwards for
> many people. Since this could happen with -g, when restarting ntpd for
> this common case, one should not use -g.
Anyway, I don't understand where the problem with -g is.
If the system time has been synchronized better than 128 ms before, by ntpd,
ntpdate, sntp or whatever, then ntpd will not step the time when it is
If the system time *is* off by more than 128 ms then the system time *will*
be stepped by ntpd anyway (maybe unless the -x, no slew option is given),
if the time offset is below the sanity limit, even if -g is not given.
If stepping the time back is Bad in general then stepping it back by 1000
second with or without -g is as bad as stepping it back by more than 1000
seconds with -g.
IMHO if this happens then this is a configuration problem, not an NTP
Maybe initial time steps should be allowed by default but inhibited if -x is
> From what I can see, it might be an improvement if ntpd had a mode that
> said "Stepping forward is OK, but do not step backwards."
> What I really think is needed is an in-depth study of the various cases,
> perhaps with some new timekeeping functions that better implement what is
I think here is a good place to discuss this, maybe in a new thread.
More information about the questions