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.42.6.71 with SMTP id 7mr28753839icz.19.1416924268167; Tue, 25 Nov 2014 06:04:28 -0800 (PST) X-Received: by 10.140.20.175 with SMTP id 44mr471868qgj.4.1416924268138; Tue, 25 Nov 2014 06:04:28 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h15no7385433igd.0!news-out.google.com!w7ni50qay.0!nntp.google.com!w8no2262067qac.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 25 Nov 2014 06:04:28 -0800 (PST) In-Reply-To: <81qc6fcqnm1t$.52r91xazm7qo$.dlg@40tude.net> 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: <188uppnlnvqgq$.1kjz3jnhjxqji.dlg@40tude.net> <87fvdd38qi.fsf@debian.uxu> <87a93l35dm.fsf@debian.uxu> <9t7t6al8bmifd9krh6koiegttgsvcovadg@4ax.com> <87d28h1cj9.fsf@debian.uxu> <3apu6ap126abi6oalch9vpre20hjij2uon@4ax.com> <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 14:04:28 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:23711 Date: 2014-11-25T06:04:28-08:00 List-Id: On Monday, November 24, 2014 4:03:25 PM UTC-5, Dmitry A. Kazakov wrote: > On Mon, 24 Nov 2014 12:30:53 -0800 (PST), brbarkstrom wrote: > > > If you want to get time standard information, you can start with the > > very short background piece from Wikipedia: > > > > http://en.wikipedia.org/wiki/Standard_time_and_frequency_signal_service > > The earth radius Re=6_371_000 m. Pi * Re / c where c is the speed of light > 299_792_458 m/s is a rough estimation of the delay the signal takes > traveling from the US to EU, ignoring refraction, interference, amplifiers, > encoders/decoders etc. This is catastrophic 67 ms. It could be improved by > statistical processing to, maybe, 10 ms or so. Now compare that with the > resolution of a typical real-time clock, which is >3 ns! > > Add here times required to sample the signal, to pass it through the system > layers, and you will understand how poor the thing is for any time > measurement (except maybe for the continental shift times (:-)). > > Fortunately, neither global time signals nor NTP is needed for time > measurements, clock drift included. > > -- > Regards, > Dmitry A. Kazakov 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. 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. 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. 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. Bruce B.