How many people are testing the client side of the pool command using a recent ntp-dev? How many of you are using IPv6?
Do you think it is ready for general release? Will a ntp.conf as simple as "pool distro.pool.ntp.org" work correctly? I'll be glad to summarize off list if you want to reduce clutter. Please send to the list(s) if you have interesting observations. ---------------- I've been running a couple of boxes using the pool command. Here is my list of bugs/quirks/comments: 1] How many servers should the pool command collect? The parameter is maxclock which defaults to 10. I don't care what the answer is, but that seems high to me. Is the pool project ready to support that much traffic? If not, we have to fix the code or make sure that the sample ntp.conf in all the distros include setting maxclock correctly. Should the default maxclock be (automagically) "fixed" if the parser finds a pool command? 2) ntpq -p doesn't show the selected servers until they respond. ntpq -c lpeers does show them. This really complicates debugging. https://support.ntp.org/bugs/show_bug.cgi?id=1956 ntpq -p doesn't show recently added pool servers 3) When the pool command adds a server, it doesn't fire off a request packet. You have to wait a polling cycle for the first one. See above comment. This makes it look like things aren't working for some mysterious reason. https://support.ntp.org/bugs/show_bug.cgi?id=1957 Slow startup if using the pool command I haven't seen (or rather not-seen) the 2-3 combination with IPv4 recently. The startup delay may have been fixed, or there may have been some interesting configuration that was needed to tickle this. I do not-see it with IPv6 when trying to talk to an IPv6 server without any IPv6 connectivity. But lpeers doesn't show it either. ??? Does peers and lpeers work correctly with IPv6 hosts? If you want a test case, try pool clock.isc.org on a system without any other pool commands or IPv6 connectivity. You get things like this: 12 May 01:48:59 ntpd[8582]: Soliciting pool server 2001:4f8:2:d::1d But it never shows up in ntpq -p or ntpq -c lpeers 4) There is a problem with too much logging and/or too many DNS probes. I thought I sent in a bug report but I didn't find it with a quick search. If it needs more servers, it tries again every 64 seconds. That's a lot of logging if things are broken. I think it needs something like exponential backoff. 12 May 01:50:05 ntpd[8582]: Soliciting pool server 2001:4f8:2:d::1d 12 May 01:51:09 ntpd[8582]: Soliciting pool server 2001:4f8:2:d::1d 12 May 01:52:26 ntpd[8582]: Soliciting pool server 2001:4f8:2:d::1d 12 May 01:53:20 ntpd[8582]: Soliciting pool server 2001:4f8:2:d::1d 12 May 01:54:32 ntpd[8582]: Soliciting pool server 2001:4f8:2:d::1d 12 May 01:55:38 ntpd[8582]: Soliciting pool server 2001:4f8:2:d::1d 12 May 01:56:38 ntpd[8582]: Soliciting pool server 2001:4f8:2:d::1d A simple test case is "pool your-favorite-server" ------------ What other things should we really really do before the next release? There is another can of worms in this area, but it isn't either pool or IPv6 related. The problem is that the answers from pool and server commands interact with restrict commands. We need to make sure that the people setting up the default ntp.conf that gets shipped with various distributions does something sensible. server and pool config lines should automatically do a restrict-allow https://support.ntp.org/bugs/show_bug.cgi?id=1568 server, peer, and pool commands should do an automatic restrict trust https://support.ntp.org/bugs/show_bug.cgi?id=976 -- These are my opinions. I hate spam. _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
