Date: Fri, 2 Feb 1996 00:46:16 -0600 (CST) From: mailing list account <lists@argus.flash.net> To: freebsd-questions@freebsd.org Subject: Re: good NTP servers Message-ID: <199602020656.AAA01252@argus.flash.net>
next in thread | raw e-mail | index | archive | help
As promised, I am passing this along to the list... I think that this will clear up many misconceptions on exactly what UTC is and how it is obtained (Including some of mine, and some of yours)... > Date: Thu, 1 Feb 1996 13:47:21 -0700 > From: jlevine@time-A.timefreq.bldrdoc.gov (Judah Levine) > To: jbryant@argus.flash.net > Subject: The Definition of UTC > > Hi, > > > okay... I'm going to try to get the official word here... > > It seems illogical that NIST would be synched to USNO, it follows > > everything that I've heard that it is the other way around where > > USNO would synch to NIST. > > > I'm Cc:'ing this to someone who should be able to answer this > > question: > > > "Between NIST and USNO, who obtains synch from whom, and how"? > > This is actually a complicated business, and a one-sentence answer > won't explain all of the complexity. So, here goes ... > > There is an international agreement about time-keeping (and other > similar physical standards) which is called the Treaty of the Meter. > The US and almost all other countries are signatories. The international > standard of time is called UTC (with no subscripts). It is maintained > by the International Bureau of Weights and Measures (BIPM, in French), > which is located in Sevres, just outside of Paris. The BIPM computes > UTC using data from about 250+ cesium clocks and hydrogen masers located > in the laboratories of many of the signatory nations. (In the US, both > NIST and USNO contribute clock data for this computation.) The BIPM > computation is done once each month, and the results are available > about three weeks later. For example, the computation for October, 1995 > was published by the BIPM on 16 November. > > Since the computation of UTC is always after the fact, timing > laboratories (such as NIST or USNO) provide an extrapolated real-time > version of UTC for users, which is identified by the name of the laboratory. > Thus UTC(NIST) is a time-scale generated by NIST from its own clock data (an > ensemble of cesium clocks and hydrogen masers). The BIPM publishes > the offset between its official UTC and the UTC implementation of each > contributing laboratory. The publication is called "Circular T" and is > publicly available. UTC(NIST) is steered towards UTC each month using > these data so that the difference is as small as possible and the steering > is as smooth as possible. The maximum change in rate of UTC(NIST) from > month to month is +/- 2 ns/day. These steering corrections are intended to > be small enough so that all but the highest accuracy users will not be > affected by them. > > The steering corrections (and related information) are published by NIST > in advance in the NIST Time and Frequency Bulletin. The difference > between UTC and UTC(NIST) varies somewhat from month to month, but is > generally not larger than 20 ns. > > The procedures at the USNO differ in detail, but the concept is > the same -- UTC(USNO) is generated from their local ensemble of clocks and > is steered towards UTC as published by the BIPM using periodic adjustments. > > Thus in the short term, UTC(USNO) and UTC(NIST) are free-running > cesium/hydrogen ensembles which are steered towards the UTC published by > the BIPM once each month. The difference between the two is of the order > of nano-seconds, which is only significant for the highest-accuracy users. > > Although this is complicated enough, it is still not the whole story -- > There are two other inputs to the UTC computation. > > The International Earth Rotation Service (IERS), located at the Paris > Observatory, is responsible for deciding when a leap second is needed to > keep UTC as computed by the BIPM and as realized by the various timing > laboratories within +/- 0.9 s of UT1 -- a time-scale based on the rotation > of the earth. This decision is based on various world-wide astronomical > observations. The BIPM and all standards laboratories implement these leap > seconds as required -- about once a year and usually at the end of June or > December. The last one was at the end of December, 1995. > > The second input to UTC is from primary frequency standards (as > distinguished from the commerical cesium standards that provide the > day-to-day data for UTC and UTC(lab). There are only a few of these > in the world; the best ones are at NIST and at PTB, the German > equivalent of NIST located in Braunschweig, Germany. These standards > are designed to realize the highest-possible accuracy. Our current > standard is called NIST-7. It took almost 10 years to build and has > an absolute accuracy of about 1e-14. It, and its counterparts in > the PTB enter the UTC computation as periodic adjustments to the > length of the UTC second -- the rate in other words. The BIPM > incorporates these data by periodically adjusting the rate of UTC. > A typical adjustment is on the order of 1e-15 in frequency. Again, > these adjustments are intended to be small enough so that only > the highest-accuracy users need to be concerned with them. > > All timing laboratories use GPS signals to transfer time and > frequency information, but the method we use is called common view, > which means that we all look at a specific satellite at a specific > time and average the observations for 13 minutes (for technical > reasons). The tracking schedule (the list of which satellite to > observe when) is published by the BIPM periodically, and all > timing laboratories everywhere adhere to it as a minimum. This > method tends to cancel many of the errors due to the satelite > clock and some of the uncertainty due to the propagation of the > signals through the atmosphere. The average jitter on a common- > view measurement with 1 day of averaging is about +/- 2 ns. Note that > this is much better than can be obtained by observing GPS signals directly, > since the common-view method cancels out many of the fluctuations > in GPS time (both thost that are due to fluctuations in the clock and > the atmosphere and those that are intentionally applied by the > controllers). > > There were a number of other side-issues raised in the note that > you sent, but I think I have answered the primary question. If you > have more questions, please ask. > > Judah Levine > Time and Frequency Division > NIST Boulder > 1 February 1996 Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602020656.AAA01252>