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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
