[ntp:questions] Client taking a long time to sync after clockchanged
jason at extremeoverclocking.com
Wed Aug 22 17:11:16 UTC 2007
> Well, my original message hasn't made it through moderation yet, but I
> found a solution to my 'problem'. I used "tinker stepout" to decrease
> the required time between clock steps. By setting it very low (10
> seconds) I can get the sync time down to a couple of minutes, which
> should be fine. I suspect this is one of those Bad Ideas, but it
> seems to be working for me.
You have to realize that NTP works on the premise of gradual changes. Once
your computer time is synced, in theory there shouldn't be anything that
would cause it jump by 2 minutes, so NTP would make sure the time change
wasn't a problem on the network or NTP server side before bumping the client
back in sync. If NTP started making drastic assumptions every time a server
was not reachable or their time varied greatly from the local clock then the
whole system would not work. It's kind of like the old saying "Measure
twice, cut once..."
> I also changed burst to iburst since it doesn't seem to have any
> effect other than increasing network traffic. The client re-syncs
> pretty quickly with iburst since the server goes unreachable then
> reachable after the clock change.
burst is used when the server is reachable.
iburst is used when the server is unreachable (typically initial sync, or
after you have lost contact for a while).
> One more question: is there a way to change the time it takes to
> declare a server unreachable? In other words, can I declare it
> unreachable after just a couple of missed polls instead of 8? These
> machines are all on a local network with not much traffic, so in
> reality if they miss more than one poll the server is probably really
> gone, or has stepped, or something.
Well, you already have your minpoll set as low as it will go. Your
computer's time shouldn't wander off *that* much while the server is
unreachable and as long as the other sources are okay then NTP should be
P.S. Only 2 servers is not a good choice. Which one is right? Nobody
knows... If you had 3 then you could determine that much better, typically
the recommended is 4 though. So you might want to add a couple more, even if
the other servers are a lower stratum that are having to be synced over the
More information about the questions