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 w4mr21935195yhc.2.1416864896290; Mon, 24 Nov 2014 13:34:56 -0800 (PST) X-Received: by 10.140.84.21 with SMTP id k21mr66926qgd.6.1416864896273; Mon, 24 Nov 2014 13:34:56 -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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!s7no1632589qap.1!news-out.google.com!w7ni50qay.0!nntp.google.com!w8no2126396qac.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 24 Nov 2014 13:34:56 -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: <653831fc-2aa6-4558-9ee3-abf16244efa6@googlegroups.com> Subject: Re: how to analyze clock drift From: brbarkstrom@gmail.com Injection-Date: Mon, 24 Nov 2014 21:34:56 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 3233 X-Received-Body-CRC: 1072271213 Xref: news.eternal-september.org comp.lang.ada:23701 Date: 2014-11-24T13:34:56-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 > http://www.dmitry-kazakov.de Usually we don't have to worry about things travelling at 7 km/sec (typical Low Earth Orbits satellite ground track speeds) or 7 m/ms. Maybe that's of some comfort. Of course if Google has to map stop lights at 1 cm resolution, maybe they need ns time resolution so they can stop their driverless car for a stop sign. (:))- Bruce B.