Stratum one autonomy and assumptions about GPS

Gary E. Miller gem at rellim.com
Tue Aug 30 04:29:59 UTC 2016


Yo Eric!

On Tue, 30 Aug 2016 00:08:17 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller <gem at rellim.com>:
> > > 1. GPS outage length and frequencies are decreasing  
> > 
> > Don't care.  If you need your NTP to work, you need to know it is
> > working. Otherwise failure are not noticed.  
> 
> OK, the test for "know it is working" is: you have lock, or you had
> lock less than x seconds ago where x is a worst-case of your drift
> model to whatever confidence interfal you want to fix.

Not THE test, A test.  Your test would catch few of the failure modes I see.

> > I don't agree.  I monitor all my services 24x7, and I do get NTP
> > problems in my logs.  
> 
> And you also said in recent mail that you don't work with the kind of
> hardware a serious autonomy-seeker would use.  So *your* NTP problems
> are not determinative, though they could be useful input data for
> improving error-estimation techniques.

Correct.  There is NO determinative solution, because their is NO
determinative use case.

I suspect we could probably come up with about 5 use cases, each
with VERY different needs.  A guy that needs good time to keep his
OAUTH/DNSSEC working has very different time stability needs than
someone doing audio work, or harder still video work.

And if that guy doing OAUTH or DNSSEC just needs it to shop Amazon his
uptime needs are very different than someone running a ton of DNSSEC zones.

Yet they are all perfect condidates for a GPS/NTP solution.

> > Not the majority failure mode.  
> 
> That's an interesting statement.  What *is*, in your experience, the
> dominant failure mode.

The GPS goes nuts and start spitting out crazy time.  Or no time at all.

As previously discussed, there are many causes to get those two effects.

> > > 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.   
> > 
> > We can't define a single tolerable error budget.  We can provide
> > some ranges of options for the user.  
> 
> And that's exactly what I've been pushing towards - to develop some
> statistical modeling on the basis of which we can make estimates to
> whatever confidence bound the user wants to set as a parameter.

A good friend of mine was a former statistician.  He gave it up and
became an engineer.  He said you only use statistitics until you start
to understand the problem.  Then other sciences take over.  He hated
starting to get a handle on the problem, then some specialist would
solve it.

So, when you fall back on stats, it is because you don't really know what
is happening.  And yes, clearly we can not even agree on failure modes, so
we needs more stats, and that just leads us to a few interesting problesm to
colve.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160829/7872cbe2/attachment.bin>


More information about the devel mailing list