Re: [gpsd-dev] Clarifications needed for the time-service HOWTO

[Eric S. Raymond]

Gary, heads-up: there are some issues you have to field in here.

Miroslav Lichvar <address@hidden>:
> I've read the current text of the howto from git and I've some
> comments. I didn't try to make it as a patch as I'm quite bad at
> writing documentation, but hopefully someone else will be able to
> select what's important and put it in a proper form. Thanks for
> working on the howto, it's definitely going to be useful.

Thanks.  Understanding complex systems by documenting them is an old
trick for me - I first did it in 1979 when I learned LISP by writing 
a manual for an implementation running at Rutgers University.  I have
found this approach extremely effective and recommend it to others.

> I understand you don't want to go into the details much, but
> technically the delay is measured by the client. Perhaps it would be
> more correct to say "I received your request at time X, I'm sending
> the reply at time Y and the propagation delay to my source of time is
> Z".

Done.

> > Ordinary client computers are normally configured to get time from one
> > or more Stratum 2 (or less commonly Stratum 3) servers. With GPSD and
> > a suitable GPS, you can easily condition your clock to higher
> > accuracy than typical Stratum 2; with a little effort you can do
> > better than many public Stratum 1 servers.
> 
> Higher accuracy than the servers have or the accuracy I'd have if I
> configured my ntpd to only use the NTP servers as my source?

Ah yes, there is that distinction between accuracy at the source chimer
and accuracy *delivered by* the source chimer.  I will clarify.
 
> > With KPPS it is very doable to get the system clock stable to &plusmn;1
> > uSec.  Otherwise you are lucky to get &plusmn;5 uSec, and there will be
> > about 20uSec of jitter. All these figures were observed on
> > plain-vanilla x86 PCS with clock speeds in the 2GHz range.
> 
> Should there be a note that the overall accuracy is affected by the
> delay in the interrupt processing? It is very difficult to measure and
> from some reports I've seen it's usually few microseconds. Getting the
> synchronization stable to hundred nanoseconds doesn't mean the clock
> will be also as accurate.

The figure of "8 microseconds" for this has been tossed around during the
discussion. I've debated adding language about this but am concerned that
people might take it as a hard number rather than an order-of-magnitude
indication.

What do the assembled experts recommend?

> > .Summary of typical accuracy
> > | Stratum 2 NTP time  |  &plusmn;100mSec
> > | Stratum 3 NTP time  |  &plusmn;200mSec
> 
> These figures look out of date. In the current Internet, I think the
> typical accuracies are at most few tens of milliseconds, 200 is way
> too much.

These figures are from the End Run Technology page on Stratum 1
(cited).  I have been unable to find another public source that is
willing to commit itself to an accuracy bound.  If you know of one or
more, by all means point us at them; they'll go in the references.

> > If you are scratch-building your Linux kernel, the configuration
> > must include these two lines:
> > CONFIG_PPS=y
> > CONFIG_PPS_CLIENT_LDISC=y
> 
> They can be compiled as modules too.

Noted.  I thought that was probably the case but was not sure enough
to change Gary's language on my own hook. I have now done so.
 
> > 2. gpsd will be unable to renice itself to a higher priority.  This
> > action helps protect it against jitter induced by variable system
> > load. It's particularly important if your NTP server is a general-use 
> > computer that's also handling mail or web service or development.
> 
> Does this matter with KPPS? Probably not.

Not *much*, but GPSD still has to do some processing after KPPS
delivers the pulse.  That could be affected by load and priority.
I think this can stand.

> > # GPS Serial data reference
> > server 127.127.28.0 
> > fudge 127.127.28.0 time1 0.420 refid GPS
> > 
> > # GPS PPS reference
> > server 127.127.28.1 prefer
> > fudge 127.127.28.1 refid GPS1
> 
> Why is the message time source used when PPS is available? It works
> with PPS alone, but the extra source might improve the robustness if
> PPS goes bad. With the noselect option it might be useful for
> monitoring.

Is the above a paragraph you are proposing for inclusion?

> > With this configuration, ntpd will read the timestamp posted by gpsd
> > every 64 seconds (16 non-root) and send it to unit 0. 
> 
> IIRC ntpd reads the SHM segment once per second (root or not). The
> minpoll and maxpoll options control how often are the collected data
> processed and used to update the clock. Should there be a section on
> tweaking the minpoll and maxpoll options? The optimal poll interval
> depends on how stable is the system clock and how noisy is the time
> source.

There will be such a section if you write it. ;-)
 
> > To keep ntpd from preferring NMEA time over PPS time you can add an
> > over large fudge to the NMEA time.
> 
> That sounds like a bad advice to me. If you don't want ntpd to use the
> NMEA time, don't put it in the config or add the noselect option or
> add the prefer option to the PPS source.

Gary, this sounds like reasonable criticism, especially about using
the 'prefer' option rather than a crocky value for the fudge.  Respond
please?

> > You should always have at least two fallback chimers in your ntpd.conf
> > for proper ntpd operation, in case your GPS fails to report time. And
> > you'll need to adjust the offsets (fudges) in your ntp.conf so the
> > SHM(1) time is consistent with your other reference clocks. We'll
> 
> Shouldn't that be SHM(0)?

Gary, this one is for you too.

> > chrony is an alternative open-source implementation of NTP service,
> > originally designed for systems with low-bandwidth or intermittent
> > TCP/IP service.  It interoperates with ntpd using the same protocols,
> 
> Interoperates with gpsd?

No. You're the second person to make this completely reasonable
mistake.  The point is that chronyd speaks NTP just as ntpd does.
I'll clarify.

> > gpsd can provide reference clock information to chronyd similarly to
> > the way it talks to ntpd.  The advantage to using chrony is that the
> > PPS time resolution is in nanoseconds.  This is 1,000 times more
> > precision than the microsecond time resolution provided to ntpd.  When
> > gpsd supports the new ntpd protocol this difference will disappear,
> > but chronyd is still simpler to set up.
> 
> I don't think chronyd is simpler to set up, its configuration file is
> very similar to ntp.conf. But there could be other advantages and
> disadvantages of using gpsd with chronyd instead of ntpd. Link to
> http://chrony.tuxfamily.org/manual.html#Comparison-with-ntpd ?

The assertion that chrony is easier to set up is Gary's.  Perhaps he
will defend it.  What I will do is add a link to this comparison anyway;
it looks very informative.

> > # delay 0.0 is right, but use 0.2 to avoid NMEA
> > # time fighting with PPS time
> > refclock SHM 0 offset 0.0 delay 0.2
> > refclock SHM 1 offset 0.0 delay 0.0
> 
> Similarly to ntpd, it's not necessary to use the NMEA time if PPS is
> available.

Gary says "Splitting these notifications allows ntpd to use its normal
heuristics to weight them." Would you two please discuss this and arrive
at a conclusion I can put in the HOWTO?

>              The delay option allows the source to overlap with other
> sources and avoid the falseticker status. The offset option is
> identical to the ntpd's fudge time1 option, should the SHM 0 offset
> value in the example be 0.420 to correspond with the ntpd example?

We are now beyond the limits of my present knowledge. If you and 
Gary discuss the matter perhaps I will become enlightened and be
able to write something down.
 
> The easiest way to determine the offset with chronyd is probably to
> configure the source whose offset should be measured with the noselect
> option and a long poll, let chronyd run for at least 30 minutes and
> observe the offset reported in the chronyc sourcestats output. For
> example:
> 
> SHM 0 configured as:
> refclock SHM 0 poll 8 filter 1000 noselect
> 
> # chronyc sourcestats
> 210 Number of sources = 6
> Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
> ==============================================================================
> SHM0                       21   9   85m      4.278      4.713   +495ms  8896us
> SHM1                       20   8   307      0.000      0.002     +0ns   202ns
> mort.cihar.com             21   8   72m      0.148      0.798   +668us   490us
> vps2.martinpoljak.net       6   4   17m    -53.200    141.596    -24ms    15ms
> ntp1.kajot.cz              25  16   91m     -0.774      1.494    -11ms  1859us
> ntp1.karneval.cz           17  10   89m      0.127      0.539  -4131us   574us
> 
> In this case (Garmin 18x) the offset specified in the config for the
> SHM 0 source should be around 0.495.

Added as a new section "Chrony performance tuning".
 
> > To get chronyd to connect to gpsd using the more precise socket
> > method add this to your /etc/chrony/chrony.conf file (replacing ttyXX
> > with your device name):
> 
> The SOCK refclock is a replacement for SHM 1 as it serves only the PPS
> data. If the time message data should be used too, the chrony config
> should have a SHM 0 refclock line.

Gary, would you please patch the configuration example appropriately?
I'm afraid to get in the middle here.

> Also, chronyd needs to be started before gpsd so the socket is ready
> when gpsd starts and drops the root privileges.

Added that.

> > Note that a chimer can be a poor performer (what the inventor of NTP
> > whimsically calls a "falseticker") for either of two reasons. It may
> > be shipping bad time, or the best routes between you and it have large
> > latency variations.  (Large but fixed latencies can be compensated out
> > using a fudge.)
> 
> A source will be marked as falseticker only if it serves bad time or
> is outvoted by multiple sources with incorrect time, not when the
> delay is large or asymmetrical, because the large delay is included in
> the intervals used in the NTP source selection algorithm.

I wasn't talking about large or asymmetrical but *variable*.  Are we
really disagreeing here?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>