From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 11:47:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22EF516A4CE for ; Wed, 10 Nov 2004 11:47:08 +0000 (GMT) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC46043D3F for ; Wed, 10 Nov 2004 11:47:07 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id iAABkkuH063795; Wed, 10 Nov 2004 06:47:00 -0500 (EST) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 X-Sender: bs663385@127.0.0.1 Message-Id: In-Reply-To: <20041110044547.GD23357@odin.ac.hmc.edu> References: <20041109190853.GA9301@nunotex.local> <20041109203416.GA13154@odin.ac.hmc.edu> <20041109224405.GA6932@tara.freenix.org> <20041110044547.GD23357@odin.ac.hmc.edu> Date: Wed, 10 Nov 2004 12:38:29 +0100 To: Brooks Davis From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" cc: Ollivier Robert cc: Nuno Teixeira cc: "Thomas T. Veldhouse" cc: freebsd-current@freebsd.org Subject: Re: 5.3-R: /etc/ntp.conf doesn't exist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2004 11:47:08 -0000 At 8:45 PM -0800 2004-11-09, Brooks Davis wrote: > At a glance these guidelines seem reasionable, but it doesn't appears > that having 4-5 upstreams and having a file that just works are > compatable. If you want to protect yourself against at least one falseticker, you have no choice but to use at least four upstream time servers. Brian Utterback can explain the math better than I can, but that's the simple facts of the matter. > So long as we're not at risk of swamping a server like one > of the AP vendors did, having something that just works is going to > trump following the recommendations exactly. It's not clear to me that > you can do both at the moment. IMO, it's really lame to say that you > should use at least 5 servers and then only provide a stable way to > access 3 of them. If 5 is the recomendation, there should be > 3.pool.ntp.org and 4.pool.ntp.org entries. I wrote most of the TWiki entry that you read, based on comments I got from a variety of people, including fellow contributors to ntp.org/ntp.isc.org and knowledgeable participants on the comp.protocols.time.ntp newsgroup. Adrian runs the pool.ntp.org stuff as a separate project, and I've been trying to get him and the other members of the timekeepers@fortytwo.ch mailing list to contribute content to the TWiki, or to just give me feedback that I can use, but I have not yet been able to get any of them to do so. Most of the public support stuff has been moved from ntp.org over to ntp.isc.org (bugzilla is the last thing to be moved over), but even before that, Adrian's project was pretty much a completely separate effort and the only thing it shared with anything that the rest of us were doing was the ntp.org domain name. It used to be something totally different under Adrian's own domain name, but Dr. Mills liked the idea well enough that he worked with UDel to get pool.ntp.org delegated to Adrian's machines, so that he could run that part of his project totally separate from everything else, and largely without interference or interaction with anything else. Note that many of the servers in the pool are on ADSL or other low-bandwidth personal lines, do not have great clocks, running older NTP server code or alternative server code which might cause problems for people running a modern ntpd, and the monitoring system right now also has some problems. For example, the recent issue that caused all of pool.ntp.org to become empty since the monitoring system was offline and it thought that all of the servers were offline, so it dutifully removed them all from the respective zones. My understanding is that the concept for pool.ntp.org was to provide decent-enough additional time sources in most cases for the majority of people using the system, without necessarily any regard for locality of reference (if you're using the top-level pool.ntp.org zones, those servers could be anywhere in the world), and definitely without being the primary source of time for most people. If you are a customer of a local ISP that has one or two time servers that they provide for your use, then using your country-code/regional pool.ntp.org zone is a perfect way to fill in the extra slots that you want/need to get up to the minimum level you should have in order to protect yourself against falsetickers. If your country-code or regional sub-zone doesn't have enough servers in it, then you can always take one step higher. Providing the [012].whatever.pool.ntp.org zones is a hack to get around problems that some people have with broken resolvers which don't implement round-robin correctly, and prevent configurations from working where you list the exact same "server pool.ntp.org" line multiple times in your /etc/ntp.conf. But it's just a hack. Do keep in mind that some server operators in pool.ntp.org are already complaining about individual ill-behaved clients that are hitting them once or twice a second, and firewalling them off. Then there was the recent incident when a small, heretofore unknown, provider of network equipment from the UK decided to ship out an update to their platform and pretty much got the entire pool.ntp.org server operator community in an uproar due to excessive traffic. It took a few days to find out who the provider was, then a few more days to convince them to fix their software, and then it took a few more days for the rollout to occur and to get most of their small customer base fixed. If you're interested in reading more about this topic, go to the archives of Adrian's timekeepers mailing list and search for things like "netpilot", "Guidelines for large scale use", and "excessive traffic?". In the meanwhile, I've been trying to do what I can to help various projects get their own NTP configurations into more reasonable shape, based on what is currently in the TWiki. > If you have specific recomendations to fix the file, please make them. At the very least, if you're going to put [012].pool.ntp.org in your default /etc/ntp.conf file, you certainly couldn't hurt yourself any worse by also including northamerica.pool.ntp.org, europe.pool.ntp.org, and asia.pool.ntp.org, since all of the servers listed in the lower level pools also get listed in the higher level pools, and you can be reasonably certain that you're already going to get a world-wide distribution of servers within the [012].pool.ntp.org lists no matter what. Assuming no broken resolvers, and given the total number of servers currently listed in the pool, there should be relatively little chance of collision between the [012].pool.ntp.org and the .pool.ntp.org zones, and you should result in getting five or six distinct IP addresses for ntpd to use. > Perhaps ntp.org should provide such a file. I'm not convinced that we can provide such a file. Each different platform is going to have their own ideas of where log data should be sent, where statistics files should be kept, etc.... What might work for FreeBSD might not work for NetBSD and certainly wouldn't work for OpenBSD, and Linux would be a totally different ballgame altogether. Then there are the other 20+ platforms that we support, including non-*nix related OSes as Microsoft Windows NT/2000 and VMS; embedded platforms like QNX and VxWorx; ancient versions of Unix such as Ultrix, DomainOS, and SunOS 4; as well as a wide variety of "modern" Unix and Unix-like OSes. If we were to provide a standard default configuration file that was required to work equally across all platforms, it would have to be stripped of all features other than specifying a set of at least four servers to be used. Certainly, we can provide information and advice to the relevant projects and the people doing NTP-related work on those projects, and we are interested in doing whatever we can to help get everyone to an equally high level of performance, quality, and robustness of configuration. But I have to believe that there's going to be some project-specific parts to those configurations files, and we can't specify or dictate what they should be -- nor do I believe that we should try. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info.