[ntp:questions] More Granularity in the US in the NTP Pool

David L. Mills mills at udel.edu
Sun Sep 16 03:24:10 UTC 2007


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 <74CdnW83I6w0uHrbnZ2dnUVZ_obinZ2d at megapath.net> hal-usenet at ip-64-139-1-69.sjc.megapath.net (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
> 




More information about the questions mailing list