Revised results on time-service accuracy

[Eric Raymond]

In previous email, I wrote:

>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've since fixed a minor misunderstanding between my profiler and gnuplot.
As previously promised, I can now separate RS232 transmission time from
gpsd's analysis time.

For the bufferbloat project's purposes, the important news is that reanalysis
has confirmed the relatively small (~70msec) skew between GPS time and the
NTP-corrected system clock.  I'm also still not seeing chaotic variation.

In other news: At 9600bps, total fix latency is a little higher than I
previously thought (about 0.40sec) and RS232 I/O time does not swamp
analysis time as completely as I expected.  However, doubling RS232
speed to 19200 cuts typical total latency to about 0.28 sec.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Where rights secured by the Constitution are involved, there can be no
rule making or legislation which would abrogate them.
        -- Miranda vs. Arizona, 384 US 436 p. 491