[time-nuts] Does GPS time reception work everywhere all of the time?

[Hal Murray]

bill at iaxs.net said:
> I'm involved with time synchronization of control system computers for
> multi-national businesses. GPS springs to mind as a way to synchronize time
> anywhere. Or is it? What about monsoon rains?

> The Internet is available almost everywhere that control computers are used,
> but many users prefer to use a data diode between them and the Internet.
> Control computers are now essential for manufacturing processes. Some of the
> processes run constantly for years without stopping for any kind of security
> update. Some of the downtimes cost millions of dollars per day.

How much does your "diode" leak?

Can you get command packets (or acks) back to your control systems, or are 
they flying deaf?


> A GPS time system allows the control systems to be synchronized in time, so
> that messages sent periodically through the data diodes will have the
> correct time stamp on various events that occur in the process.

> But does that work everywhere all of the time? Where can I find answers? 

How accurate do you need your clocks to be?
How reliable do you need/want them to be?
How much are you willing to pay?

How vulnerable/flaky is the OS on your control systems?  (Are they running 
Windows?)

Note that there are 2 dimensions to accuracy.  One is RMS error, or something 
like that.  The other is how often do you go outside some error bars, how 
long is the tail?

----------

The geeks I hang out with would put a firewall between the big bad internet 
and the system to be protected.  If you are sufficiently paranoid (which 
doesn't take much) you don't allow marketing people or visitors to connect 
their likely-to-be-infected laptop to the subnet with the protected systems.  
(You can setup another subnet for them.)

If you need sub-ms accuracy, you probably need a local GPS receiver/system.

For 10s of ms accuracy, you can run ntp on the firewall, or on a separate 
system right behind the firewall.  The accuracy depends on the network load.  
There isn't a simple answer.

If all you need is to be within a second or three, you can probably get that 
by tweaking the timekeeping fudge factor, possibly by hand.  This would take 
occasional monitoring and tuning.

-----------

Consider timekeeping on a computer.  They are all based on a crystal.  It's 
either something like "every interrupt, bump the clock by 1 ms" or it's "that 
register ticks at 1 MHz".

The problem is that the crystal usually doesn't tick at exactly the specified 
frequency.  It's off by a few to hundreds of PPM.  Low cost crystals are 
generally accurate to within 100 or 50 PPM.  The watch crystal behind the 
CMOS/TOY clock is probably much better but it's hard to use for fine grained 
timing.

There are 86400 seconds per day so 1 PPM is 1 second in 11.5 days, 10 PPM is 
(roughly) 1 second per day...


If you monitor a system for a week or two, you can calculate how far off the 
crystal is.  That's by hand, just looking at the printout from something like 
the date command, waiting a week and doing it again.

If your OS cooperates, you can tell it the fudge factor so that it will keep 
(much) better time.  (You probably need double-precision arithmetic deep 
inside the timekeeping routines.)

That will get rid of most of the systematic error.  You can tune things by 
watching it drift over following weeks/months.


One complication is that the crystal frequency is slightly temperature 
dependent.  Ballpark numbers are 1 PPM per 10 F.  (or maybe 10C?)    A system 
will keep better time if there is good air-conditioning and/or you don't prop 
open the door very often.

Another possible complication is software bugs/quirks.  Current Linux kernels 
get different answers each time they reboot and calibrate the TSC clock.  The 
differences can be 200 PPM.  A kernel patch would fix that, but that's a pain 
if you don't otherwise need to maintain your own kernel.  I've been told it's 
been fixed.  I haven't tested it yet.

------------

Story mode:

Shortly after I got to Xerox in 1976, Ed Taft fixed a bug in the Alto 
timekeeping routines.
  http://en.wikipedia.org/wiki/Alto_%28computer%29
The Alto was designed to run at 170 ns.  You buy crystals in MHz rather than 
ns.  They got 5.88 MHz crystals.  When the software guys wrote the 
timekeeping code, they used 170 ns rather than 170.068.  That's off by about 
400 PPM, enough to be annoying.  Tweaking one constant was enough to fix 
that.  (I forget if he had to rewrite that code to use double precision.)


-- 
These are my opinions, not necessarily my employer's.  I hate spam.