Preliminary results of using GPS to look for clock skew
esr at snark.thyrsus.com
Wed Sep 21 19:02:05 EDT 2011
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
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
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
More information about the Bloat-devel