[ntp:questions] More Granularity in the US in the NTP Pool
Henk Penning
henkp at cs.uu.nl
Thu Sep 13 14:22:02 UTC 2007
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
--
---------------------------------------------------------------- _
Henk P. Penning, Computer Systems Group R Uithof CGN-A232 _/ \_
Dept of Computer Science, Utrecht University T +31 30 253 4106 / \_/ \
Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/
More information about the questions
mailing list