Re: Non-GPS derived timing sources (was Re: NTp sources that work in a datacenter)

[Marshall Eubanks <tme () multicasttech com>]

Hello;

GPS maintains a set of its own clocks at Falcon AFB and does not really
track or steer to TAI - however, they are very close in practice 
(except that the AF did not know
about Leap Seconds when they started out and synced it to UTC in the 
early 1980's -
thus, there is a 19 second offset between the GPS time system and TAI.)

Every major time service and most national standards labs maintain a 
set of clocks of comparable accuracy - US, UK, France, Germany, Russia, 
Japan, Australia, etc., so there is no shortage of timing info to 
compare it with.

The International GPS Service (IGS - http://igscb.jpl.nasa.gov/ - a 
collaboration between
various geodetic and time service users of GPS -
has a rapid service with information including clock offsets with 17 
hours latency
see http://igscb.jpl.nasa.gov/components/prods_cb.html  for data 
availability.

These solutions are NOT based on the official DOD tracking data but 
instead on the
much more accurate carrier phase (and are not affected by either 
Anti-Spoofing or
Selective Availability  when these are turned on - see 
www.timingtechnologies.com/Gpswp1.pdf
for a description of these degradations for civilian users). There is 
no doubt  that a major perturbation
in the GPS clocks (say, several 100 nanoseconds as is typical with SA) 
would be detected by the IGS
within 24 hours.

These was a pilot program set up to use these data for official time 
transfer - see
http://maia.usno.navy.mil/gpst.html for a host of details. I do not 
know its status since Jim Ray
left the USNO.

GLONASS maintains another set of clocks and satellites.
Of course, once Galileo is launched there will be yet another source of 
time sync.

All of this is important if you need synchronization at 100 nanoseconds 
or better.
LORAN will not give you this by several orders of magnitude - nor will 
WWVB nor
NTP. If you do care about time at this level, get at least a Rubidium 
clock and sync it
to GPS. If you do not, I would not worry about it even at the highest 
paranoia levels -
there  are other equally paranoid people who will start screaming well 
before you notice.



On Sunday, June 1, 2003, at 09:57 PM, David G. Andersen wrote:

> On Sun, Jun 01, 2003 at 08:13:08AM -0700, Peter Lothberg quacked:
> > > I don't expect GPS to spin out of control soon..
> >
> > So GPS tracks TAI and the difference is published (2 months after the
> > fact..)
> >
> > But it's simple to build a 'jamer' that makes GPS reception not work
> > in a limited area, same for Loran-C used in combination with GPS in
> > many Sonet/SDH S1 devices.
> >
> > > but I did wonder how
> > > hard it is to find a another reliable clock source of similar 
> > > quality to
> > > GPS to double check GPS.
>
>    For NTP purposes, WWVB is actually just fine, as long as you 
> properly
> configure your distance from the transmitter.  The NTP servers list 
> shows
> several WWVB synchronized clocks.  CDMA clocks synch indirectly to GPS,
> but are typically locally stabalized by a rubidium or ovenized quartz
> oscillator with decent holdover capabilities for a few days of GPS 
> outages.
> But they'll suffer the same fate if GPS went just plain wrong.
>
>    The NIST timeservers are available over the net, if you can deal 
> with
> that degree of synch.  Lots of them just use ACTS dialup synch to get 
> the
> offset, and have very good local clocks.  ACTS is certainly a good 
> fall-back
> for GPS, since it uses a wired path instead of a wireless one.
>
>   So if you're really paranoid:  GPS + WWVB + ACTS + internet to 
> tick/tock or
> one of the NIST primaries.  Ultimately, WWVB, ACTS, and ntp to NIST are
> all synched from pretty much the same source, but the odds that they'd
> all go bad are pretty slim.  GPS is steered from the USNO time, but the
> clocks on the satellites are pretty good.
>
>     -Dave
>
> --
> work: dga () lcs mit edu                          me:  dga () pobox com
>       MIT Laboratory for Computer Science           
> http://www.angio.net/
>       I do not accept unsolicited commercial email.  Do not spam me.
                                 Regards
                                 Marshall Eubanks


T.M. Eubanks
Multicast Technologies, Inc.
e-mail : tme () multicasttech com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/