[ntp:hackers] Swimming in the pool

David L. Mills mills at udel.edu
Tue Oct 16 17:29:28 UTC 2007


Brian, Danny,

I see this issue in two parts, one to obtain and manage a candidate 
list, the other to select and maintain an optimal subset of truechimers. 
I feel competent to manage the latter, but it would be nice if somebody 
else could do the former. Note that the counter I mentioned is separate 
for each association, so each is independent of the others. Brian's 
comment about comparing a new candidate with short poll interval with 
old geezers with long poll interval is valid; however, the candidates I 
see are not very good - delays over 100 ms - mean that the dispersion 
increment at 1024 s is only 15 ms, so the difference doesn't really matter.

Interesting that the European servers consistently bump the American ones.

Dave

Brian Utterback wrote:

>
>
> 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
>
>



More information about the hackers mailing list