Re: how to analyze clock drift

[brbarkstrom@gmail.com]

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.