Stratum one autonomy and assumptions about GPS

[Achim Gratz]

Eric S. Raymond writes:
> Achim Gratz <Stromeko at nexgo.de>:
>> Forget about GPS outages.  If you want to connect these time servers to
>> the net, they should have some form of sanity checking that's
>> independent from their primary time source and take them off the net as
>> soon as something looks fishy.
>
> What kind of sanity checking do you recommend?

I'd think that keeping two or three known good servers as noselect would
go a long way in that scenario.  Could even be a pool statement,
although personally I'd opt for at least five servers in that case.  If
more than one of those servers are more than 10ms either way from your
time, something is going on that shouldn't be.  If it's other stratum-1
sources then you should likely see below 1ms (2ms tops) unless the
network totally flakes out.  Since ntpd doesn't do anything with
noselect sources the actual logic of taking the stratum-1 offline in
case of problems would need to be delegated to some monitor process.

The message offset relative to the PPS is recorded somewhere in ntpd
(you can set up the extended statistics to spit it out), so if that
starts drifting from the expected value (fudge2) the clock should become
suspect.  The same goes for sudden changes in the local frequency
offset.  Again would need to be an external process that does the health
monitoring.

Another thing would be to have more than one refclock, but ntpd
currently doesn't support that very well.  Part of that is that you
seemingly can't have more than one pps-gpio for whatever reason.  The
other part is that you can't tell ntpd which clock you expect to be more
accurate and how to switch from one to the other.  That would need new
code to support it from within ntpd I think.

As I said before, I'm planning to use a microcontroller to integrate
GPS, DCF77 and maybe an OCXO into a time box.  I'm currently looking at
a controller that has Ethernet w/ PTP support (hardware timestamps), so
it could be a completely autonomous dual-protocol timeserver.  But a
less capable controller might just produce PPS and a serial stream and
connect to a rasPi or other server for a resilient stratum-1.  That
would use the Uni Erlangen format, like the Meinberg clocks.

> My recipe/HOWTO does emphasize that you need 1PPS for Stratum 1 service.
> Beyond that I don't know there's much I can do to head off operator error.

There's no way to prevent stupidity and malice, yes.  But since the goal
is (IIUC) to get more stratum-1 servers onto the net, some education
how not to shoot yourself into the foot is in order.

> How do you fudge a 1PPS source?  What do you have that you consider
> more accurate?

You are only talking about an aligned PPS source, not frequency PPS,
right?

The NMEA driver in PPS mode has noth a PPS offset (fudge1) as well as an
NMEA message offset (fudge2) parameter.  I haven't used the ATOM/prefer
combination in a while, but IIRC, ATOM can be fudged as well.  If the
PPS is done via pps-gpio the offset should be below a few milliseconds.
I can't be sure of my own offset better than about 2…4ms due to the
asymmetry of the DSL line, but to get the same time as the PTB servers I
need to fudge about 1.7ms with the navSpark mini.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada