Stratum one autonomy and assumptions about GPS

Hal Murray hmurray at
Thu Aug 25 23:14:05 UTC 2016

esr at said:
> One of my agenda items for a while has been to develop a protocol for places
> that want to firewall out NTP for security reasons - that is, a set of
> practices and error estimates based on documented assumptions. 

Background data is good.  I think you will get into trouble if you try to 
turn that into useful recommendations.  There are too many assumptions and 
there will be huge differences between places.

> Right.  This sort of thing you hedge against with tell-me-three-times.
> (Remember that the user story assumes a big hardware budget.) 

If you have a big budget, you buy a does-it-all box with GPSDO and NTP 
server, and pay a defense contractor to integrate things.

> I don't think I need to care about specific causality much.  The overriding
> question is what the statistical distribution of outage lengths is.

The time pattern depends upon the mechanism.  If your GPS unit fades out 
several times a day you can collect useful statistics.  If your GPS screws up 
due to a 1024 week rollover it's hard to get enough data to work with.

> (Rain/snow on your trees.  Why is this special? Does it increase multipath
> reflections or something?) 

Water attenuates GPS signals.  So wet trees/roofs attenuate more than dry.

>> Your 10ms error budget may be fine for some applications
>> but others may want better. 
> In general they're going to need to go with PTP over a LAN. I'm focused on
> Stratum 1 for WAN time service. 

You can easily get better than 10 ms over a LAN.

With a bit of care, you can do it on a WAN.  An overloaded last-mile link 
will make that harder.


I think you are mixing two uses for good background data.  Earlier you said 
your target was a firewall blocking all NTP traffic to the WAN.  Now you are 
back to running a WAN server.

My bottom line is that collecting data is good but it's going to be hard to 
turn it into useful recommendations.

When you are collecting data, please be sure to get the next layer of 
details: hardware, OS, software, versions...  It's probably best to save the 
log files too.  That part is easy if you save everything.  Then you just need 
to know the date/time when you collected the data.

These are my opinions.  I hate spam.

More information about the devel mailing list