[MAMS] [Mw] Computer clock

[John Hawkinson]

I don't think Tom's explanation really captured the computer time sync
issues.  More below.

Gerald K5GW <TexasRF at aol.com> wrote on Sun, 30 Aug 2015
at 08:37:11 -0400 in <197d70.50b8e41d.431452f7 at aol.com>:

> Is there no computer hardware add on that will keep the correct time  
> directly without all these latency issues?
> 
> I have spent some google time looking for such but nothing was
> found. Seems like a really fundamental solution; what am I missing
> here?

There absolutely are, and you are.  Properly configured, an NTP
(Network Time Protocol) client should get within several millisecond
of accuracy. Of course, that is not what a stock Windows machine does.
Install NTP if you care.


Tom Williams <tomw at wa1mba.org> wrote on Sat, 29 Aug 2015
at 22:30:14 -0400 in <55E26AB6.8070402 at wa1mba.org>:

> Time on the cell networks is GPS based, and until recently there
> were two times being reported. One was GPS time and one was actual
> time. They are different by about 15 seconds (there have been that
> many leap seconds since the birds were launched).

This is confusing, because when we say "GPS time" some people mean "a
UTC time obtained via a GPS receiver" and some people mean "the time
that GPS uses internally, which does not account for leap seconds."
GPS time without leap seconds should never be presented to a consumer,
and any proper GPS device decodes the list of leap seconds from the
GPS almanac and applies the offset before displaying the time to the
user. Unfortunately, there have been GPS implementations that have not
done so, and there was a longstanding Android bug on some hardware
only (e.g. Motorola Droid,
https://code.google.com/p/android/issues/detail?id=5485).

> Network (Internet) based time can be off all the time. The reason is
> that packet delivery delay is random (within some boundaries).

This really isn't true at all. Any proper NTP (Network Time Protocol)
implementation record and tracks the round-trip-time variation
from packet to packet over time, and can straightforwardly
determine how much of the offset is due to queueing delay (the
number one source of round-trip variation) and how much is due to
actual time-of-flight. To a first order, "just take the minimum round
trip time over several tries"

Furthermore, NTP accounts for the round-trip delay, which it measures.
The primary problem comes in when the round-trip delay is asymmetric;
e.g., packets from New York to LA go via Chicago, but packets from LA
back to New York go via Dallas, Atlanta, and Washington.  This sort of
thing can lead to something like 50ms one way and 30ms the other way
(totally 80ms), and ntp would presume a 40ms delay (half of 80ms) and
thus be off by 10 ms.

The solution to this issue is to choose NTP servers that are close to
you, because both (1) if they are close, path asymmetries don't really
matter, and are much smaller in magnitudeand (2) path asymmetries are
much less likely in the local area.

Even if you're not using NTP, packet delays are not random. Most of
the time we can model them as Poisson distributions (also not really
right), but just take a bunch of samples and take the minimum.

> Good software measures the ping (network response time) to and from
> the source and compensates for it.

Right, this is close. Except the round-trip time isn't really properly
called the "ping" time, and sometimes the time you measure with the
ping tool isn't exactly the same as the time an application like ntp
will see, because sometimes the network treats ping packets
differently, and because hosts can respond to them faster (in the
kernel).

> The ping time is constantly changing. Only when the network is in
> really bad shape do the pings exceed 1 second. 

That's true, though it might be the norm on some really bad mobile
networks or something. Really anything about 100ms is cause for
concern domestically. From a timekeeping perspective, the concern
would be the delay variation.

> Good clock will keep time and re-ping when the source clock and
> local clock vary by some threshold.  Typical clocks will just keep
> local time and check the source on boot or once per hour, and that
> is good enough to keep well within one second of accuracy. For fun
> you can ask your computer to ping any network address and it will
> report the ping time. My windows clock synchronizes every 7 days but
> not when booted. Mine has not syncronized in 5.5 days and is off by
> 7 seconds. I forced it to update and it got to within 0.5 seconds.
> Crummy clock!

A proper ntp client measures its own drift and adjusts the local
clock frequency to compensate. But synchronization every 7 days
is kind of laughable in the precision timekeeping world.

--jhawk at mit.edu
  John Hawkinson
  KB1CGZ