An NTP Question

An NTP Question

Post by jarra » Fri, 16 Sep 2005 06:13:16

Hello all,

Its gonna be my first post, so please pardon simple and silliness of the

I have following setup:

Computer B ---> Computer A ----> External Clock Source

BTW, all are Linux machines and are running ntpd.

If I change time on B via date -s hh:mm, such that the B's time is just
2-3 mints off of
Machine A.

How long it will take for machine A to sync up with machine B ?

If and when machine B polls for time to Machine A does at that time it
corrects it clock or
it needs sevreal such sync operation to set the time ?

questions mailing list

An NTP Question

Post by Terje Math » Fri, 16 Sep 2005 19:43:27

NTP was never designed to handle badly broken situations quickly!

It will fix your problem, but only after a majority of the last 8 polls
agree that the reference time have stepped out.

I.e. with 1024 seconds between polls, it could take 1-2 hours before
ntpd will step the clock back.

If this is a common problem for you (maybe some other process which you
cannot stop, and which messes up the clock regularly?), then your best
bet is to limit the poll interval, possibly together with iburst and burst.

This way it will detect and fix jerks in less than a minute, most
probably 15-30 seconds.

"almost all programming can be viewed as an exercise in caching"


An NTP Question

Post by Richard B. » Fri, 16 Sep 2005 22:59:50

Machine B should ignore machine A's time for several poll intervals.
After machine B is convinced that machine A really believes in the new
time, it should adjust its clock at the rate of 1/2 millisecond per
second! That's thirty milliseconds per minute or about forty-three
seconds per day!! A two minute step would take almost two days to
propagate to the clients.

If machine A "steps" the time, machine B will wait for several poll
intervals before believing the that the change is correct.

Of course this is something that should NEVER occur in a properly
configured NTP network. It would not be possible unless something was
seriously broken!!!!

What problem are you trying to solve?

An NTP Question

Post by Brian Utte » Sat, 17 Sep 2005 02:32:56

Why do you think that machine B would only adjust by slewing the
clock? An offset this big would result in a clock step, not a
slew, unless the system was explicitly configured to slew large
offsets, which is not the default, nor recommended.


Remember when SOX compliant meant they were both the same color?
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

An NTP Question

Post by Richard B. » Sat, 17 Sep 2005 03:24:11

Ooops! I should have checked the documentation instead of relying on
my fading memory.

System "B" is supposed to wait 900 seconds (15 minutes) during which no
sample is received that falls inside the 128 millisecond "step
threshold". This assures, as far as possible, that the error is real
and must be corrected. It would then "step" the clock. If the error
exceeds 1024 seconds, the "panic threshold" ntpd writes an error message
to the log and commits suicide!

I can't see that the question is of other than theoretical interest
since a server should never, ever, step the time like that. The only
way I can think of to do it is to have an isolated net with a single
server serving its local clock and somebody comes along, looks at the
server's clock, sees that it's two minutes fast according to his wrist
watch, and sets the time manually! This, to me, would clearly be a
situation in which no one really cares what time it really is!

An NTP Question

Post by Tom Smit » Sat, 17 Sep 2005 04:15:42

Server boots from a power failure on a system whose hardware clock has
run slow or fast (or stopped) in the interim. It's a power failure,
so when the server comes up it can't yet reach its upstream servers
because the switches and routers are still down. It locks onto its own
local clock, configured as a backup. When the network is finally back up,
it steps to right time.

That's one. There are dozens of scenarios.