gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Final revisions to the Time Service HOWTO


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Final revisions to the Time Service HOWTO
Date: Fri, 22 Nov 2013 07:12:12 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Miroslav Lichvar <address@hidden>:
> > This preserves the reader's (justified) sense of having gained some
> > understanding of drift compensation and saves us from having to
> > explain a lot of implementation-specific details about the differences
> > in what ntpd and chrony are doing.
> 
> Well, I think that could be misleading as PLL/FLL doesn't use linear
> fit.

Yes, but that is not important for what this section is intended to
accomplish. All we need to be able to do here in order to introduce
the reader to the topic properly is to point to a technique that both
implementations use, with an exposition that gives some idea what the
constraints in the problem space are.  

The latter (building an understanding of constraints in the problem
space) is the important part! We're not actually trying to document
ntpd and chrony in *this section*, but rather to create a mental model
in the user that gets him/her to the point where he/she can later read
a qualification like "ntpd only uses linear fit at startup, switching
to PLL/FL later" without being thrown.

> The text explains how the polling interval is adjusted, but normally
> with reference clock (i.e. with gpsd) the interval is fixed. I'd suggest
> to mention that, so users are not confused when they don't see any
> adjustments in the interval.

Artful vagueness is our friend here.  New version of section:

   So how do we calculate the drift?  The general idea is simple.
   Measure the time offset every N seconds over a longer window of time
   T, plot the graph, and fit a straight line.  The slope of that line is
   the drift.  The units cancel out.  Parts-per-million is a handy scale.

   How do you turn that handwaving description into code?  One easy way
   is to set N=2 and pick the right T, then run the answer through a
   low pass filter.  In that context, there are two competing sources of
   error.  If T is too small, the errors on each individual measurement
   of the offset time will dominate.  If T is too big, the actual drift
   will change while you are measuring it.  In the middle is a sweet
   spot.  (For an example, see <<ADEV-PLOT>>.

   Both ntpd and chrony use this technique; ntpd also uses a more
   esoteric form of estimation called a "PLL/FLL hybrid loop". How T and N are
   chosen is beyond the scope of this HOWTO and varies by implementation
   and tuning parameters.

By abstracting out T and N, we avoid having to talk about fixed vs.
autoadjusting T, or what differs when N > 2, or *when* N > 2, or any
of the other implementation-specific details.  But we accomplish the
actual goal, which is to build understanding. The reader probably won't
be flummoxed if and when he learns about PLL/FLL; we said "*One* easy
way".

You are already more articulate than a lot of technical domain
experts.  I'm explaining my editorial thinking to you in detail
precisely because I think you could get as good at this kind of
expository writing as Hal Murray already is - notice that I
didn't have to change his original a lot.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]