It was brought up before about the alternative to ntpdate (which is being deprecated) being to use the server noselect option and querying ntpq.
I thought I'd give my thoughts on it, because I think it can be quite beneficial to the pool. First some background on usage... Which are documented quite well right under our noses at http://www.eecis.udel.edu/~mills/ntp/html/confopt.html. > minpoll minpoll > maxpoll maxpoll > These options specify the minimum and maximum poll intervals for > NTP messages, in seconds as a power of two. The maximum poll > interval defaults to 10 (1,024 s), but can be increased by the > maxpoll option to an upper limit of 17 (36.4 h). The minimum poll > interval defaults to 6 (64 s), but can be decreased by the minpoll > option to a lower limit of 4 (16 s). > noselect > Marks the server as unused, except for display purposes. The > server is discarded by the selection algroithm. So, "server xxx.xxx.xxx.xxx noselect maxpoll 12" tells ntpd to add the server to the list, poll it every 68 minutes (2^12 s = 4096 s = 68.26 m) and to otherwise ignore the server except to display it's stats when using "ntpq -p". <Note: It's recommended that yout increase the maxpoll, but not required. Seeing that this is the pool we want to be nice to our neighbors, right? The exception being, Ask, because he makes pretty graphs for us. :)> Everywhere you read the documentation, it suggests that you pick a set of servers "near" you. Mostly they leave it up to you to figure out what that means, some go as far as saying "near to you using PING or TRACEROUTE." This still leaves NEAR as being a vague term (maybe is should be, I don't know). I'm suggesting that we could each use noselect to monitor our NEAREST pool servers based on an ascending sort on delay. It would require a script to be run on the "ntpq -p" output(I have a rough one in the works), and maybe some graphing to see the results over time (I added 80-100 "noselect" servers removed everything after 0500 UTC with a delay > 100 and by 1400 UTC, 15 had increased to a delay > 100 once the network traffic started up). <As a side note: my server is in the list twice, once with the public IP and once with a private IP. The public is has a delay of 8 while the private IP for the same server is 0.004. Interesting how much of a difference a linksys router makes.> Other related ideas: - NTPD can be run dynamically. Why not a script to watch the ntpq output and dynamically "noselect" a server under conditions of high offset or no connection adding another server in it's place. This could be helpful with the bad servers, by having the script auto-configure 5 (debatable -- 7 for Brad ;) 2n+1, right?) servers, double that as servers to monitor with "noselect" (with a longer maxpoll of course). - Potentially, this last script could be built to coordinate peering agreements between pool servers. One could still manually specifiy peers in ntp.conf, but let www.pool.ntp.org broker peering agreements between peers at the same stratum with other criteria. - The script could be tweaked based on class of participant, i.e. large business (500+ machines), 7 servers, 14 noselect, 2 external peers; medium business, 5 servers, 10 noselect, 1 external peer; SOHO, 4 servers, 8 noselect, no peers. (These are all made up, I probably don't know what I'm talking about) - The Geocaching DNS ideas being tossed around could be tied to this. I don't know how/where the DNS servers are set up, but each regional pool could have a DNS server that would request a full list of all pool servers and monitor them, run a scoring script on the ntpq output and dynamically updating it's DNS results. - The ideas are endless... _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
