Preliminary results of using GPS to look for clock skew

[Eric Raymond <esr@snark.thyrsus.com>]

As a step toward implementation of Dave's Cosmic Background
Bufferbloat Detector, I took on the job of employing GPS as a reliable
local time source to check whether an NTP-assisted system clock has
significant skew from GPS.

Towards this end, I've just spent a couple of days rebuilding and 
improving the latency-profiling machinery in GPSD.  What this allows
me to do is collate the following pieces of data:

* The GPS's time of a fix in properly leapsecond-corrected UTC (Call this T)

* The NTP-corrected system time at which the first burst of
  fix data from the device wakes up gpsd's select(2).  Call this
  S (Start of reporting cycle) 

* When the daemon has received and processed the entire burst of packets
  constituting a reporting cycle and is about to ship JSON to the client. 
  Call this E (End of reporting cycle).
  
* When the client recieves the report.  (R = receipt time).

What's interesting is to plot the deltas S - T, E - S, and R - S as a 
stacked-impulse graph.  I can do this at will now.  More importantly,
so can anyone with my software and GPSD.  We have a working GPSD port to
CeroWRT, so our test routers can be instrumented.

The entire height R-T approximates the entire fix latency. I say 
"approximates" because, of course, T is on a different timebase than
R, S, and E, and NTP's 10ms fuzz is an issue.  But S-T gives us an
idea of the atomic-clock-vs-system-clock time.

There's nothing surprising about my setup - FIOS to an N600 running a
recent OpenWRT build to a 2.66GHz Intel Core Duo 2 machine running Ubuntu
10.04 LTS. 

Over runs of 20-100 fixes, S-T (the clock-skew figure) ranges from 66
to 76 milliseconds.  Total latency R-T is steady at about 0.38
seconds.  R-S vanishes - it's close to 0.9 milliseconds.  Total fix
latency is completely dominated by E-S, the time for gpsd to receive
and process the fix data from the GPS.  And I'm not seeing a lot of
bursty variation in these measurements.

I'm going to investigate further.  In particular, I'm going to try to
either measure or compute how much of E-S is I/O time.  My suspicion is that 
almost all of it is, and that gpsd's actual computation time is negligible
by comparison.

But preliminary indications are that NTP is in fact doing a pretty good
job of keeping my system clock conditioned. I'm not seeing bufferbloat
effects on time service.

However, I'd welcome having my code and assumptions checked. This kind
of profiling is tricky work, with large vulnerabilities to small
mistakes in detail. That's the main reason I'm describing these
results as 'preliminary'; some skeptical review is needed to soliudify
and verify them.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Let us hope our weapons are never needed --but do not forget what 
the common people knew when they demanded the Bill of Rights: An 
armed citizenry is the first defense, the best defense, and the 
final defense against tyranny.
   If guns are outlawed, only the government will have guns. Only 
the police, the secret police, the military, the hired servants of 
our rulers.  Only the government -- and a few outlaws.  I intend to 
be among the outlaws.
        -- Edward Abbey, "Abbey's Road", 1979