[ntp:questions] Client taking a long time to sync after clockchanged

Richard B. Gilbert rgilbert88 at comcast.net
Wed Aug 29 19:03:09 UTC 2007


Jason Rabel wrote:
>>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
<snip>
> 
>>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).

Burst is generally a very unfriendly thing to do.  If you don't have 
permission from the server's owner, DON'T!  What burst does is send 
eight requests at two second intervals for EVERY poll!  Burst is a 
special purpose hack.  I believe it's intended for dialup connections 
where you might connect for a couple of minutes two or three times a day.

Iburst is a very good way to initialize.  It sends the FIRST eight 
requests at two second intervals in order to fill NTP's pipeline.  This 
gets you enough information to start disciplining your clock in the 
first ten seconds.  Thereafter, the system polls at longer intervals.




More information about the questions mailing list