[ntp:hackers] NTPv4 Brian Version

Brian Utterback brian.utterback at sun.com
Mon Aug 15 19:25:50 UTC 2005


This bothers me greatly. It suggests that NTP is rather chaotic, and is 
not as resistant to falsetickers as we all believe. Perhaps more servers 
are needed than we thought? If the mitigation algorithms are as stable
and resilient as we have all claimed, shouldn't the introduction of a 
single server with bad time have no effect at all?

David L. Mills wrote:
> Your suggestion to "not want to grab as many answers as soon as 
> possible" can be counterproductive. Once things settle down and the poll 
> interval climbs to the max, a newcomer with low dispersion and bad time 
> can be quite disruptive, possibly tossing out the best server at large. 
> What works better here is to set minclock at 3 and maxclock at 4 or 5. 
> The manycast and/or pool schemes (both can be used at the same time) 
> sift only the floor/ceiling statum range, keep the first maxclock found 
> and, in the pool case, timeout the others.
> 
> Experiments here reveal the only really fair thing to do is occasionally 
> demobilize the lot and start over. Since the server seed is refreshed 
> about once per day and after that the Autokey protocol must run in order 
> to generate a new cookie, it seems reasonable to demobilize/start over 
> at that time. Since preemptable assoications are configured with iburst, 
> the client is resynchronized in seconds. These issues are not resolvable 
> by discussion and consensus, they are engineering reality.



-- 
blu

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


More information about the hackers mailing list