[ntp:questions] NTP Cheat Sheet

David Woolley david at ex.djwhome.demon.co.uk.invalid
Fri May 9 07:51:43 UTC 2008


Heiko Gerstung wrote:
> For me maxpoll is an important parameter as well because ntpd switches 
> to larger polling intervals pretty fast and for a lot of our customers 
> it is important that ntpd recognizes as fast as possible if a GPS signal 
> is lost or the GPS receiver/IRIG time code reader/AM radio looses sync 

But ntpd should only switch to a long poll interval if it believes that 
it will not accumulate a significant error if it drifts for many times 
the poll interval, so, if the poll interval is long the time available 
before you need to switch to an alternative source is also long.

I think what you are actually saying is that you believe there is a bug 
in ntpd that causes it to increase the loop time constant prematurely.

The other possibility is that you are are saying that your reference 
clocks will give out wrong times for a significant period before they 
declare themselves down, and you want the accumuated error wiped out as 
soon as possible after the clock discovers its is giving bad times. 
Even then, a long loop time constant will require bad input for a long 
time to cause real problems.

However, it looks to me as though the code only ever uses the minpoll 
value for reference clocks unless the clock driver itself actually 
overrides the NTP_FIXPOLL flag, or the poll rate, directly.  I'm not 
sure I've not missed something, though, and I don't have a system with a 
reference clock to check.


> for some other reason. They want the unit to switch as soon as possible 
> to a fallback source which will take significantly longer with a polling 
> interval of 64s when compared to 16s ... the same applies when the 
> refclock recovers after becoming unsynchronized.

There is a better case for this, always assuming that maxpoll is 
relevant for reference clocks.




More information about the questions mailing list