Danny Mayer wrote: > Brian Utterback wrote: > >> Unfortunately, neither poolcasting nor preempt does what is being >> requested, at least I know that preempt does not and poolcasting >> doesn't if I understand it correctly. The problem with preempt (at >> least) is that it only subtracts or replaces, it never incrementally >> improves. By this I mean it picks some subset of the original >> servers and throws away the rest. So, if the original set is >> sub-optimal, the final result will likewise be sub-optimal, that >> is, it only gets you the best of what could be a very bad set. >> >> Poolcasting as described by Dave, allows NTP to throw away all >> the current servers and get a new set. This is an improvement in >> that you at least get a new set to work with if the previous one >> was poor, but your chances of getting a good set are still >> the same as the first time around. >> >> > > I don't think that Dave said that he was throwing anything away except > for falsetickers from the pool. Nothing was mentioned about retrying. > One of the things that could be implemented is to fetch additional lists > of addresses if there aren't sufficient truechimer servers in the > current set. That's a suggested addition right now. > > I am not sure if the information I have from Dave was in a public forum or private email, but it was definitely the case that the preempt code is supposed to replace all of the servers at once and not only those ranked as poor. Remember, none of these are falsetickers, the preempt code just ranks them and when one of them goes below a certain threshold, replaces them.
The reason for replacing all of them is that the way the selection code and ranking code works, there is a preference made for new samples. If you only replaced a small number of servers, the samples from these servers are of necessity more recent than the samples from the older servers. Because the dispersion has a time component, the new samples will be favored and the new servers can force the old servers to be ranked poorly and thus thrown out on the next round. >> What Henk has described is just the first step in a facility that I >> have been thinking about for quite some time. The idea is to allow a >> much more extensive level of self-organizing emergent NTP behavior. >> But the ability of get this type of incremental behavior is >> crucial to getting it to work. >> >> > > Please explain more about what you are suggesting. > Just an area I have been intrigued by. Nothing ready to share yet. > Danny > >> Brian Utterback >> >> > > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
