Re: nptd not changing time.

[Nick Holland <nick_(_at_)_holland-consulting_(_dot_)_net>]

Kelly Martin wrote:
> I'm running ntpd on OpenBSD 3.6-release with default config. The
> daemon is running and finding a big time difference, but it's not
> changing the time. 

That's not what your log shows.

> Here is a partial log entry:
> 
> Dec  2 11:39:59 Jesu ntpd[20331]: adjusting local clock by -566.282920s
> Dec  2 11:44:02 Jesu ntpd[20331]: adjusting local clock by -565.378171s
> Dec  2 11:45:18 Jesu ntpd[9153]: peer 200.30.141.26 now invalid
> Dec  2 11:45:34 Jesu ntpd[9153]: peer 200.30.141.26 now valid
> Dec  2 11:45:37 Jesu ntpd[9153]: peer 217.204.244.146 now invalid
> Dec  2 11:45:52 Jesu ntpd[9153]: peer 217.204.244.146 now valid
> Dec  2 11:47:33 Jesu ntpd[20331]: adjusting local clock by -564.486513s
> Dec  2 11:51:04 Jesu ntpd[20331]: adjusting local clock by -563.626742s
> Dec  2 11:53:12 Jesu ntpd[9153]: peer 200.141.215.161 now invalid
> Dec  2 11:53:55 Jesu ntpd[9153]: peer 200.141.215.161 now valid
> Dec  2 11:54:03 Jesu ntpd[20331]: adjusting local clock by -562.794721s
> 
> Is ntpd not changing the time because it's already off by such a wide
> margin (almost 10 minutes)? 

oh, come on.
The first snip you show is 566 seconds off.
The last one is 562 seconds off.
That's four seconds of progress in 15 minutes or so.  Not bad.

> I don't understand the "now invalid" and
> "now valid" messages, above.

that's just the machines it is talking to to set the time.  If every
machine it was talking to was always available and always working
perfectly, ntpd could be really simple.  It isn't.  Don't worry about it.

> I searched the archives of this list, and found someone who said (1)
> that ntpd tries to set the correct time when it's first run, even when
> there's a big difference, 

This is true POST 3.6, not true for 3.6.

> and (2) that perhaps rdate should be used
> the very first time, if there's a big difference. 

This was true for 3.6 and before, not for -current.

> Maybe this is
> required -- but if that's the case, why the log entries, above?

Because that's what was happening?  Fortunately, the logs are very
accurate, your descriptions were not.


For reference, it took around 11 hours to adjust two minutes:
Nov 29 21:59:42 fluffy ntpd[..]: adjusting local clock by -157.080152s
...
Nov 30 09:13:16 fluffy ntpd[..]: adjusting local clock by 0.233377s
(that was the first one that was under half a second error.)
You were off by way more than two minutes.  Relax.  Or grab the corse
adjustment knobs and give 'em a twirl.

If sudden jumps in time were acceptable, no one would worry about ntpd,
and we'd all use rdate.  When it says "Adjusting clock by.." that is how
far off the clock is, NOT "we are suddenly jumping your clock by 560
minutes" (in which case, it would say "AdjustED clock by ..."), so yes,
everything is working fine, except you are expecting to use fine
controls to fix a course adjustment.  It works, but it takes a looong time.

Adjusting time is like pulling up next to a car on the race track with
both of you running at 100mph (160kph for the enlightened) -- you make
small, careful adjustments, you don't toss a brick on the accelerator or
the brake.  (heh.  I guess rdate could kinda be like slamming on the
brakes and waiting for the other car to come back around the track and
run into you.  ok, my analogy has flaws, but it might get some points
across, and it is kinda a funny picture :)

It *seems* ntpd can advance the clock faster than it can slow the clock,
that kinda makes sense to me, at least.  Having time move backwards is a
problem...having time jump ahead a bit is not such a big deal.

Nick.
(still happy to have any clock less than 30 minutes off.  hmm... might
explain the t-shirt my GF got me: "I define on-time as when I get there" 8-)
-- 
http://www.holland-consulting.net