Hi-- On Jun 14, 2013, at 4:09 AM, Miguel Barbosa Gonçalves <[email protected]> wrote: > Greetings! > > I know that NTP resolves hostnames on startup and, after that, the NTP > packets are exchanged with only those IP addresses.
For explicitly configured servers and peers, sure. > I also understand that the NTP Pool Project design is based on this premise. Not really, no. See http://lists.ntp.org/pipermail/questions/2010-April/026304.html "As of 4.2.7p22, "pool" directives create a prototype association which stores the DNS name and options (like iburst). An async DNS query is started to resolve the pool name to IP addresses. When this completes, as long as more pool servers are desired, ntpd spins up a preemptible pool association for each IP in relatively short order. Two knobs influence the decision to stop adding pool (or manycast) associations: tos minclock 3 maxclock 6 More servers are added when either there are less survivors than minclock (+ * or o in the ntpq peers billboard) or there are less total associations than maxclock. With the above tos directive and: pool us.pool.ntp.org. iburst ntpd will immediately resolve three IP addresses from us.pool.ntp.org. and spin associations for them. The pool prototype (and any other) association counts towards maxclock, so in this confguration 5 preemptible pool associations would tip maxclock. After three preemptibles are kicked off, ntpd will wait for us.pool.ntp.org to resolve to IP addresses it's not already using, up to 270 seconds with the current pool.ntp.org DNS TTL. Then two more preemptible associations will be spun, at least. If the polling of existing servers has resulted in at least 3 survivors, no more preemptible pool associations will be started and one leftover IP address will be held for later. Otherwise, the third IP address will be used and ntpd will wait up to 270 seconds for us.pool.ntp.org to resolve to a third set of three IPs." > The question is: how effective is the monitoring platform in removing the > dead or bad (from the monitoring platform viewpoint of course) NTP servers > from running NTP clients on users' computers? The NTP pool's monitor is quite effective at removing dead or bad NTP servers from the DNS listings. Modern NTP clients using the pool directive will do a fine job of finding new timeservers as needed to retain an adequate # of peers. > This was just a rhetorical question of course. The monitoring system can't > notify the NTP daemon in the end users' computers. True, but it doesn't need to do so. > As an end user with a 24x7 powered computer I would have to check the NTP > daemon once in a while. I know the chances of all 4 of the poll assigned NTP > servers becoming bad are pretty remote. On the other hand, for a 24x7 > computer a discerning user would probably choose 4 properly administered and > maintained NTP servers close to him. I would at least. > > So it seems to me that the NTP Pool Project would be best targeted at > computers not running 24x7 or, better, might be being used mostly by > computers in these conditions. Someone who cares about NTP timekeeping and manually selects better servers is likely to do what you've suggested, but the pool doesn't really care whether the clients are up 24x7 or not. > Why then isn't it possible to allow users willing to provide their bandwidth > to the project to use their dynamic IP based servers to support the project? > > Something like a quick, say 30 minutes, convergence to a 10 score and the > monitoring platform would do a DNS resolve when the server stops responding > perhaps because the user changed it's IP address. > > Any arguments why this is not a good idea? The typical lease time for dynamic IPs varies widely; some folks might renew their DHCP leases or similar and keep the same IP for long enough to provide useful time service, but others will have the IP change in a matter of hours, which is too short to be useful. In addition, most folks running with dynamic IPs have clauses with their ISPs forbidding them from running servers. Regards, -- -Chuck _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
