Henk, Mitigation code is already in the daemon, but it is really useful only for the manycast scheme. There is even a new pool command, but I haven't checked it out.
There is a mysterious server option you might not know about called preempt. Very crudely, at least now, configure say ten pool members and specify this option on the server command lines. What should happen is that all ten will be mobilized and the usual pruning process will select several of the best. A system of timers is used to manage the population at a selected level. Don't take this seriously just yet. While it's running now with manycast, and relatively short timers, to make it work properly with the pool, it needs an asynchronous resolver or at least a way to call the resolver during regulat operation. Sachim was working on these issues and was to make a candidate list from the all the poolsters in the DNS reply, not just the first one. The paint is still wet. There are more refined ways to skin the cat, but having said that, the cat perched next to me is giving a very strange look. Dave Henk Penning wrote: > In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Hal Murray) writes: > > >>>Suppose a ntpd client can pick up 5 random pool servers, and >>>periodically (say once a day) replace the 'worst' server >>>by randomly picking a new one. >> >>I like that suggestion. But, ignoring implementation details, >>how do you decide which of two servers is "better"? > > > I assumed that ntpd already ranks servers, so finding the worst > server should be feasible. Finding the 'best' replacement algo- > rithm requires further study, but I think something 'reasonable' > can be used to start supporting poolclients. > > Here is what I think would be beneficial to the pool project: > > -- A ntpd config option like > > poolclient pool.ntp.org 5 86400 > > meaning : > > initially pick 5 pool-servers from pool.ntp.org ; > every 86400 seconds (24 hours) pick a random pool-server > to replace the least useful pool-server currently in use. > > -- for poolclients, 'good' is good enough ; some 10s or 100s > of ms is close enough ; better performance is nice, of course, > but the average poolclient doesn't care too much > > -- for pool-servers, network traffic is an issue ; I believe > that allowing clients to 'search' for close-by servers, > would minimize overall ntp traffic. > > -- the linux distro's want a default ntpd config that works > worldwide > > -- IMHO, most poolclients don't care about sync/async-dns ; > if, for the time being, the 'pick and replace' method > causes a bump, that's alright. > > -- for the pool it would be nice if self-organising poolclients > were a reality soon ; even a crude implementation would be > welcome ; even if a poolclient wouldn't work too well as > a ntp server > > -- it would be nice if a pool client could retain pool-state > (the set of pool servers in use) between executions, much > like 'drift' is retained in a drift-file. > > Regards, > > Henk Penning > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
