[ntp:hackers] Swimming in the pool

Brian Utterback brian.utterback at sun.com
Tue Oct 16 16:20:44 UTC 2007



David L. Mills wrote:

> At the moment and unlike the manycast scheme, the truechimer list is not 
> refreshed. However, from what I see here, an attempt to grab a fresh set 
> of servers results in the same set returned. I haven't kept up with the 
> pool community, so don't know what the conventional wisdom is.

Eventually you should get a new list, however how long that takes is
variable.

> 
> There is one easy thing to do: Save the list of server addresses, in 
> this case all 15. If the number of truechimers is less than maxclock, 
> select random additional server addresses not already on the truechimer 
> list and light them up. If maxclock truechimers are already on the 
> truechimer list, once in a while demobilize the last (worst) one and let 
> nature take its course.

Do both. Try to get a new list, add the addresses to the existing list,
remove duplicates and save the result.

One concern I have is the method used to light up the new associations.
You and I had a private conversation a while ago about the dangers of
adding a new server to a group of existing servers, particularly if the
old servers had a particularly long poll interval. The new server would
get preference because it would tend to have newer samples, forcing an
oldtimer off the list and then repeating the process with a new server.
Thus the list would tend to churn rather than stabilize. Perhaps when
a new server is added via this mechanism, it should be added at the
longest poll interval in use by an active (not KOD'ed) existing
association? I think that stability is devoutly to be wished, but I also
am a very big fan of small incremental improvements. In fact, I would 
rather temporarily bump up the max clock number by one, add a new 
candidate and then later restore maxclock, letting the algorithm toss
the worst one.

Another thing, is how to treat unreachable servers? When you said "every
poll message", do you mean every one, no matter to which server? Then
unreachable servers will be handled. But what about if all of the
servers become unreachable, say by a network outage? There shouldn't
be a problem for a day or so, because the servers will still be on the
truechimer list, but won't their data eventually become too stale to
use, bumping them off the list? Then they will all increment on each
poll and all of them get tossed at the same time, leaving no servers
at all when the network comes back. Maybe increment only for polls
that get a response?

> 
> I'm tossing this over the fence for suggests, comments and Bronx cheers. 
> Discussion woulad be welcome.
> 
> Dave
> 
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers

-- 
blu

"You've added a new disk. Do you want to replace your current
drive, protect your data from a drive failure or expand your
storage capacity?" - Disk management as it should be.
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom


More information about the hackers mailing list