[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