From owner-freebsd-questions Wed Jan 31 00:10:04 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29295 for questions-outgoing; Wed, 31 Jan 1996 00:10:04 -0800 (PST) Received: from pelican.com (pelican.com [206.16.90.21]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA29244 for ; Wed, 31 Jan 1996 00:09:38 -0800 (PST) Received: by pelican.com (Smail3.1.29.1 #10) id m0thXbb-0000SMC; Wed, 31 Jan 96 00:09 PST Message-Id: Date: Wed, 31 Jan 96 00:09 PST From: pete@pelican.com (Pete Carah) To: questions@freebsd.org Subject: Re: good NTP servers In-Reply-To: <199601261806.LAA04921@phaeton.artisoft.com> Sender: owner-questions@freebsd.org Precedence: bulk In article <199601261806.LAA04921@phaeton.artisoft.com> Terry writes: > >Since we are on a sort of tangent here, I might as well add to it. 8-). Even further on a tangent, and some corrections...: (someone else threw in:) >> tick.usno.navy.mil and tock.usno.navy.mil are sync'ed to Navy Cesium clocks, >> I am assuming [someone please correct me if I am wrong] that these clocks >> are sync'ed in a method similar to that described on pp 10 and 11 of NIST >> Special Pub 432, as the Cesium sources at the USNO are traceable to NIST. The other way around; USNO syncs NIST. >> The method described on pg 10 is accurate to less than 100ns, this is >> utilizing GPS... this is pure assumption based on the fact that the >> Cesium Primary Standards in use at the USNO are tracable to NIST, and >> that NIST uses the GPS method as described to sync the Primary standards >> at WWV, WWVB, and WWVH. You can do much better than 100ns with averaging periods of days; I've seen the GPS sync unit at WWVH and I'm not sure exactly how it's used but it isn't a short-term correction to the local cesium source. As far as I know it's used for a long term rate correction. >> Since all three sites are using NIST tracable Cesium Primary Standards, >> I guess that would make all three sites stratum 1 servers... sorry folx... USNO's ntp sites aren't directly sync'd to cesium standards; they use H-masers that are in turn sync'd to cesium standards. (h-masers are more short-term stable). The computers apparently do use their standard cheap crystals for the cpu clock, though they may have modified oscillators there too. I don't know how much their kernel timekeeping is modified; ours is substantially modified from standard BSD. (they run HPUX which is often gratuitously different from "normal" unix...) >The inaccuracy on pg 10 is due to pseudo-random "jitter" in the GPS >signal. The Navy, being a branch of the US military, has access to the >generator and key pair and so GPS is significantly more accurate for >them Not totally true for USNO; they define GPS time so the codes are not relevant for what you're worried about. They do need to use the codes in keeping PPS in sync; most civilian receivers don't use PPS at all and those that do use it only for a noise source. >(many airports in the US are generating adjustment base references >for GPS based on known lattitude/longitude positions of the adjusting >signal source to defeat this intentional inaccuracy in the GPS position >fixing for non-military grade GPS). which works pretty well. Note that the FAA's differential system is *not* yet in service, and probably won't be for some years. The Coast Guard's diff system isn't geared up to improve time measurements, though it could probably halve the jitter over a few-second period. Given that the receiver jitter is much less than the possible transfer accuracy from a GPS receiver to a freebsd system (a few microseconds), SA hardly matters... The imposed jitter per satellite is up to 300ns (it actually can be somewhat more); the time measurement can be quite a bit better if the least-squares solution is used to update a Kalman filter with a few-second or longer period. (Tom Clark of NASA claims 40-50ns on non-SA-corrected Motorola receivers with standard microcode; see his ftp site, which I forget right now). This is about as good as the receiver can be considering its 10mhz internal clock source. SA specs call for a 100 meter horizontal uncertainty in location 95% of the time. What they don't tell you is: 1. What is the offset the other 5%; i've seen 1/4 mile on rare occasions. 2. The time constant or other nature of the distribution. It is *not* unbiased on any one satellite, nor is it anything like gaussian. It is entirely possible (I don't think they do this) for them to keep the error at 99 meters all the time, wandering randomly around a circle with one side favored most of the time (though it is hard to arrange this for very long for more than one location on the earth...) 3. The vertical uncertainty is about twice the horizontal (this is a geometric problem having to do with the fact that you can't see the sat's below you). 4. They do promise that the apparent velocity due to SA alone of a point fixed on the earth will be less than some (about a knot) speed. Many hand-held GPS receivers have some hysteresis at 0 speed so that it takes a constant speed for some period of time or a few knots speed for less time, before it will display non-0. Mine (GPS45) will follow a fast walk pretty well, though. If you have a cheap (or even expensive) GPS with a map mode, go to constant-time update on the map at the smallest scale, and wait an hour or two and look at the resulting plot. It can be interesting :-) For real accuracy, there are some post-time differential master stations on the web; JPL (topex/poseidon) operates one of them. >The Navy's clocks are probably accurate to much better than 100ns if they >are using military grade GPS. Actually the USNO clocks are the *definition* of time for the US; NIST is sync'd to them via GPS. See http://www.usno.navy.mil/ under the 'directorate of time' link for details. USNO are *not* _using_ gps; it's the other way around. They feed the gps system its sync (probably via the USAF). Their NTP servers claim "a few 10s of microseconds". At least they have a decent connection to the civilian internet; if they went through the normal milnet gateways they would have more of both delay and jitter than ntp can decently handle. (hundreds of milliseconds) NTP on a T1 has around a millisecond of uncertainty, depending mostly on the router traffic (about half that on an unloaded circuit). Therefore whose stratum-1 source you look at is not terribly relevant unless you are doing things that need more precision than ntp can deliver anyway, or you are on an unloaded ethernet with a st.1 machine. -- Pete