Re: [amsat-bb] Atomtime

["Louis A. Mamakos" <louie@xxxxxxxxxxxx>]

And of course, if you have a full-time Internet connection, you could
just run a full NTP (Network Time Protocol) implementation on your
computer.

NTP has sophisticated alogithms to compute a clock delay and offset
between your host and each remote clock peer it's executing the protocol
with.  Due to the nature of packet swtiched networks which it runs over,
it needs to compute a filtered version of the offset and delay values,
typically using a median filter over the previous 8 samples.  This has
the effect of discarding outlying sames due to transient network
effects.

NTP will also select between a number of clock peers to choose the one
which is will synchronize to.  The algorithms here will  discard clocks
which would appear to be high-quality baseded on the quality of the path
over the network to the clock, and the claimed precision if that clock
is "way out of whack" with respect to the other clocks it's running the
protocol with.   Within NTP circles, this is referred to "false-ticker
detection."

When a reference clock is chosen, the job now is to synchronize the
local clock.  Actually, what you have is a model of a local clock
to which you're attempting to synchronized both the frequency and
phase.  The local clock is modeled as a phase-locked loop, where the
filter and gain of the loop are varied based on "how close" the
clock is, and the quality (dispersion or noisiness) of the offset/delay
samples.  The effect is that as you get your clocks phase offset
closer to zero, the PLL becomes a bit "stiffer" and less likely to
change frequency.

This local clock model is applied to the real time-of-day clock on
your computer by typically asking the OS to gently slew the time time
slightly; typically no faster than 10 milliseconds per second.  This 
ensures a continuous and "smooth" clock for applications running on the 
system.  Of course, if your local clock is way off, you must apply a step
adjustment, which is very rude.  (And of course, stepping the clock
invalidates the local offset/delay samples).

Over high quality network paths (which is not to say low delay, but low
delay variance), you can synchronize clocks to sub-millisecond precision.

Over even not-so-good paths, you can determine the frequency error of
your local clock to a fairly high degree of precision.  Many years ago,
I was able to tell the temperature in my office based upon the computed
frequency error of the not-too-well temperature compensated oscillator
in my UNIX workstation.

If you're running one of the open-source BSD varients or Linux, you
can easily run NTP.  The UNIX NTP daemons will typically save the
computed frequency error into a file.  The local clock model will apply
this base-level frequency correction in the absense of clock offset
(phase) error measurements from the time you reboot your system.

How rude and crude to just "reset" the clock on your computer every
few hours!

I was co-author of the first UNIX implementation of NTP in 1988.  Clock
synchronization over networks is a lot of fun, (and a sickness, really).

louie
wa3ymh
----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org