On Sun, 28 Jan 2007 13:45:45 +0100 (CET) "Henk P. Penning" <[EMAIL PROTECTED]> wrote:
> Agree. If ntpd was 'pool aware', it could evolve the client's > set of pool servers. > > For instance, If the client uses 4 pool servers, it could (daily) > throw out the worst server and replace it by a randomly chosen > other pool server. > > I think this would quickly converge to a good, stable set of > servers for each client. Clients would drift towards using > 'close by' servers. This would benefit the pool because overall > traffic would decrease. And if it works, we no longer need the > regional pools. > > Is this a good long term strategy for the pool ? > > Henk Penning I think that a guaranteed "daily throw out the worst server" will lead to local hot ntp hosts getting all the traffic and adds an additional short term variable to ntp accuracy. A slight revision of the above idea may be to use a scoring system over a longer term. Similar to how the servers are ranked in the pool. NTP already uses "reach". A poor reach history over say one week could trigger a dropping and random replacement with a new pool server. To prevent replacing a "long term reach problem" with a new "short term reach problem", the reach criteria could be more strick in the first 24 hours. By useing a reach threshold vs. a "drop the worst server daily" you eliminate the constant shifting of servers and a migration to the best of the best, which I think would lead to a few servers getting pounded while other sit nearly idle because the do not have the best connection. Additionally, or as an alternative option, the NTP daemon could keep a score card on how often each server is listed as a "candidat" or a "sys.peer". Again a threshold would be used and if a server is rarely a candidate then it could be replaced. _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
