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

[Miroslav Lichvar]

On Sat, Oct 19, 2013 at 10:35:47PM -0400, Eric S. Raymond wrote:
> This thing is coming together nicely.  But, Gary, I need to extract
> more information from your head (and from other founts of expertise
> such as Hal and Harlan) before it will it will be anywhere near
> complete.

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.

Quoting from the document:
> NTP service daemons running on each host do clock synchronization in
> the presence of variable network latency by monitoring those delays in
> real time and passing around messages that say, essentially, "I
> believe it is time X and that my propagation delay to you is Y".

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".

> 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?

> With KPPS it is very doable to get the system clock stable to ±1
> uSec.  Otherwise you are lucky to get ±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.

> .Summary of typical accuracy
> | Stratum 2 NTP time  |  ±100mSec
> | Stratum 3 NTP time  |  ±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.

> 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.

> 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.

> # 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.

> 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.

> 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.

> 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)?

> 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?

> 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 ?

> # 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. 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?

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.

> 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.

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

> 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.

-- 
Miroslav Lichvar