Stratum one autonomy and assumptions about GPS
Stromeko at nexgo.de
Thu Aug 25 18:51:43 UTC 2016
Eric S. Raymond writes:
> I shall now discuss three interlocking reasons this possibility does
> not loom as large in my mind as it does in Hal's.
> When I think about this, I consider 10ms total deviation from UTC as
> the target for WAN service. Let's say your local clock drifts by 3ms
> per hour. Then you can tolerate a GPS outage of a bit over 3 hours
> before you will start shipping bad time. I have *never* seen a GPS
> outage that long, even with older hardware.
The MTTR doesn't tell you anbything about the tail of that distribution,
which is more likely caused by other unlikely events, like some squirrel
gnawing through the antenna cable, a cat taking it'Äs hunting instinct
out on the GPS puck or (since we're talking about long-running services
on hardware that's really not designed for that as the rasPi) a memory
corruption getting to some sensitive spot.
> My observed worst case these days is about 20 minutes, and that is *rare* -
> usually only when cold-booting. For that to be intolerably long, the local
> clock would have to drift by 30ms per hour. Actually I seldom see outages
> longer than 5 minutes, which implies a critical drift of 120ms/hr. And
> this is with my consumer-grade hardware, indoors of a windowsill with
> trees outside.
I've been running my rasPi 2 more or less non-stop for about a year, save
for the reboots when a new kernel gets installed. It has crashed or
otherwise shown signs of memory corruption three times in that period.
The B+ hasn't had any such problems, so my guess is these are related to
the PSU. The point is, you'll have to expect that some portion of these
systems will be run unsupervised for quite some time, so they need to
look after themselves.
> We may already be at a technological place where GPS outages don't bust the
> tolerable-error budget, even with cheap hardware. If we aren't, we'll
> probably be there soon. One of my medium-term agenda items is to measure
> and see.
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. I frequently see .GPS. falsetickers in
NTPpool (actually the last month I haven't seen them, so maybe they've
been kicked out) that are/were 50ms and more out, which tells me they
have either not bothered to determine the fudge factors or run without
PPS. You don't want to see that kind of stratum-1 clock on a larger
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
More information about the devel