[ntp:questions] failing-over flaky upstream servers

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Sun Mar 15 18:27:03 UTC 2015


On 2015-03-12 11:46, Paul wrote:
>> Drop local driver as that is intended for systems with an external
>> clock source providing an accurate disciplined system clock.
>
> That doesn't quite make sense to me.  (To be sure we are talking about
> the same thing, I assume you are referring to my "server
> 127.127.1.0".)  My use case appears to align with the documented [1]
> examples.  I /do/ want it to be the "designated time server to act as
> a primary server to provide synchronization to other clients on the
> network" [paragraph one], and "the clock of last resort when all other
> normal synchronization sources have gone away" [paragraph two] and
> "when an external discipline source [like a modem] is available"
> [paragraph three].  Well, not a modem, but an external NTP source is
> available at least a couple of times a day!  Of course, perhaps I'm
> not understanding correctly, so do please tell me again if you think
> including the local clock is bad.

Local driver was intended for use with a disciplined hardware clock
as in PHK's classic GPS/RbO/PLL/Soekris/FreeBSD setup
http://phk.freebsd.dk/soekris/pps
which kept offset < 130ns, stability < 1E-11 @ 1 hour, 1E-14 @ 1 day;
or a non-NTP kernel driver and similar custom setups used by national
labs, and time-nuts who occasionally post here, with decent clock
sources: Cs, Rb, H-maser e.g. NIST DO
http://tf.nist.gov/general/pdf/2478.pdf
USNO PTP
http://tycho.usno.navy.mil/ptti/2010papers/paper9.pdf

I have never seen the local clock driver operate at a stratum other
than 16 (disabled).
NTP-dev documents "To further protect the Internet infrastructure from
accidental or malicious exposure to this driver, the driver is disabled
if another source is available and operating.", recommends not using this
driver, and configuring orphan mode.

> Thanks for your detailed input.  Let me know what you think about the
> local clock, if you significantly disagree with my fudge factor on
> driver28 and if you think the NMEA driver (20) is significantly better
> than the SHM driver (28) for my particular case.

See above about local clock; fudge is whatever centres your offset about
zero, for your choice of a measure of central tendency, and minimizes your
clock error terms - jitter, wander.
Does gpsd support any NMEA timing smarts or tweaks? Has ESR or others done
any timing studies on gpsd NMEA handling, and SHM latency and jitter?

-- 
Take care. Thanks, Brian Inglis


More information about the questions mailing list