[ntp:questions] Re: ntpd, boot time, and hot plugging

Brad Knowles brad at stop.mail-abuse.org
Fri Feb 4 17:02:42 UTC 2005


At 2:47 PM -0200 2005-02-04, Alain wrote:

>>      Any time you switch interfaces, get a new IP address, or any of
>>  the other things that are typical for mobile environments, you're
>>  basically looking at a complete stop and restart, if not a complete
>>  stop, re-configure (presumably with totally different servers), and
>>  re-start.
>
>  Woldn normal operation cope with that? If it is a server at all,
>  continue with calculated historical drift. If both sets of servers
>  are in ntp.conf, after a while it will acquire sync again.

	The way ntpd works is that it looks up the IP address of the 
interfaces it is listening on when it boots, and then it explicitly 
binds to those IP addresses.  It never again looks up that 
information.  So, when your IP address changes, you have to restart 
ntpd.  You have the same problem if you switch interfaces.


	If you briefly lose connectivity, and you keep the same 
interface, and you keep the same IP address (maybe you were walking 
around in your house and were in an area that doesn't have good 
wireless coverage for a while), then you can help make recovery 
easier by configuring the LOCAL refclock.

	With a LOCAL refclock, if all the other servers go away, ntpd 
will at least continue running in degraded mode and using the latest 
calculated variables, and while the stratum value will drop (to 
whatever you fudged for the LOCAL refclock), it won't go out of 
state=4, and will start recovering as soon as you regain connectivity.

	If you don't have a LOCAL refclock, I'm not entirely certain what 
will happen, but it most likely won't be good and you will have to 
restart.

>  Maybe just be a bit more tolerant to a situation where all servers
>  become unavailable?

	Within limits, you can address that with a LOCAL refclock.

	Of course, not all vendors ship ntpd compiled with support for a 
LOCAL refclock, so you may have to rebuild your own ntpd binary.

>  And maybe just use longer times to calculate drift if connection times
>  are not stable. Just a parameter adjustment maybe?

	You should leave that up to ntpd.  These algorithms have been 
developed the hard way over thirty years, and unless you're Einstein 
or Dr. Mills, you're unlikely to be able to improve on them.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.



More information about the questions mailing list