[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