From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.61.132 with SMTP id w4mr27425140yhc.2.1416948652389; Tue, 25 Nov 2014 12:50:52 -0800 (PST) X-Received: by 10.182.76.70 with SMTP id i6mr20223obw.35.1416948652265; Tue, 25 Nov 2014 12:50:52 -0800 (PST) Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!w8no2359521qac.0!news-out.google.com!c9ni23868igv.0!nntp.google.com!h15no7621441igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 25 Nov 2014 12:50:51 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=50.111.125.244; posting-account=Ies7ywoAAACcdHZMiIRy0M84lcJvfxwg NNTP-Posting-Host: 50.111.125.244 References: <87k32oi7r8.fsf@debian.uxu> <98h17atrhtl9kitthjf8ukt1f7rk1ribvc@4ax.com> <8761e54qt2.fsf@debian.uxu> <119jk3v83ilwp$.94ppz78taoc4.dlg@40tude.net> <81qc6fcqnm1t$.52r91xazm7qo$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: how to analyze clock drift From: brbarkstrom@gmail.com Injection-Date: Tue, 25 Nov 2014 20:50:52 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: number.nntp.giganews.com comp.lang.ada:191025 Date: 2014-11-25T12:50:51-08:00 List-Id: On Tuesday, November 25, 2014 1:15:56 PM UTC-5, Dennis Lee Bieber wrote: > On Tue, 25 Nov 2014 06:04:28 -0800 (PST), brbarkstrom declaimed > the following: > > > > >The third reference in my previous post mentions software NIST provides > >that give time signals from NIST in several formates. One format is the > >Network Time Protocol (RFC-1395), where "The NIST servers listen for a NTP request on port 123, and respond by sending a udp/ip data packet in the NTP > >format. The data packet includes a 64-bit timestamp containing the time in > >UTC seconds since January 1, 1900 with a resolution of 200 ps." I think > >that should probably be sufficient for the 3 ns accuracy desired in determining > >clock drift. > > > Note that part of the NTP protocol (or receiving computer > implementations) also incorporates lots of stuff to determine correction > factors for the receiving computer and the latencies in the network. > > As a result, it is not as precise as you may want it to be. > > http://en.wikipedia.org/wiki/Network_Time_Protocol > """ > NTP is intended to synchronize all participating computers to within a few > milliseconds of Coordinated Universal Time > """ > and > """ > NTP can usually maintain time to within tens of milliseconds over the > public Internet, and can achieve better than one millisecond accuracy in > local area networks under ideal conditions. > """ > > Note that: milliseconds > > NTP is used to synchronize wall-clock time between computers by bouncing > packets between them, but does not provide a fixed/stable clock signal > itself. > > > > >I suspect that it might also be possible to get time from a gps-equipped > >smartphone. Since the GPS satellites maintain atomic time and are carefully > >cross-checking with ground stations, they are probably a potential source > >of data for this problem. > > > Yes, but ... > > The time at the receiver is adjusted by fitting the delays from the > satellites... One reason you need four satellites for a decent fix... you > have to fit a local time along with distances from the satellites to > determine location. They are a source for standard time these days... > Consumer GPS and phones likely have a simple quartz clock for normal > time-keeping that gets updated when ever a GPS fix is performed. > > For a computer lab, a standard time base is something like this > http://www.arbiter.com/catalog/product/model-1084a-b-c-gps-satellite-precision-time-clock-%2840ns%29.php > but again it is only meant to synchronize the wall clock time of disparate > computers [the equivalent of setting your watch while listening to a time > announcement on a radio]. You have to move up to > http://www.arbiter.com/catalog/product/model-1083b.php to get standardized > frequency outputs which can be used for clock differencing. > > >More exotic solutions might be uncovered from a bit of further research. > >For example, the astronomers doing Very Long Baseline Interferometry need > >to do remote time synchronization of high accuracy. I don't know the > >methods they use, but maybe they have something that could be turned into > >a useful tool. > > > Probably boxes like the above 1083b or 1084a -- depending upon whether > they need a civil time-stamp or a reference frequency (you'd need the > latter to calibrate a receiver, for example -- and wouldn't be using NTP > with its latencies; rather you'd be using a distribution amplifier and lots > of carefully measured coax so that the signal gets delivered to all end > points at the same time). > > >Finally, after thinking about your response a bit, I think the average time > >delay between a WWWV station in the US and a receiver in the EU would be > >fairly constant -- except for variations due to changes in the index of > >refraction and reflected signals bounced off the ionosphere. The constant > >part of the delay becomes an offset in a linear regression data reduction. > >Of course, this is minor quibble with your comment. > > > If you are in the EU, you shouldn't be using WWVB (WWV is an AM > voice/tick signal [though there is a BCD subcarrier]; WWVB is a digital > signal for automated setting of clocks). The UK has MSF on the same 60kHz > as WWVB, and Japan has JJY. {I suspect those are the stations my watch > handles as all three are on the same frequency and just need to decode the > strongest signal -- the Citizen Skyhawk will identify which US/EU/JP was > used on the last synchronization}. > > http://en.wikipedia.org/wiki/Time_from_NPL > http://en.wikipedia.org/wiki/WWVB > > > -- > Wulfraed Dennis Lee Bieber AF6VN Thanks for the information and the cautions. Hopefully, these items may be helpful to the original poster of the problem. Bruce B.