Re: [art] summary of updates - draft-time-touch

[Joe Touch <[e-mail]>]

> On Apr 18, 2017, at 8:02 PM, John Hawkinson <[e-mail]> wrote:
> 
> Joe Touch <[e-mail]> wrote on Tue, 18 Apr 2017
> at 08:03:38 -0700 in <[e-mail]>:
> 
>>> The '25ns' sillyness of GPS with respect to TAI is still there. I now have
>>> an idea where the 100ms for NTP is coming from. That's really sad.
>> can you clarify?
> 
> A problem here is that your ID conflates a known offset with
> with a typical uncertainty with a theoretical maximum uncertainty.
> You label the field "d-TAI" and name it a delta, but it isn't one.
> And the name is evocative of DUT1, which is different kind of thing.
> 
> It might be better to adopt a standard name for this field
> (uncertainty? imprecision? +/-?; I am not sure) rather than coining
> your own.

Uncertainty sounds good.

> 
>> The 25ns of GPS is the result of a claim in the GPS spec.
> 
> You should probably cite it explicitly.

I'll dig that one up.

> 
>> The 100ms is from a claim in NTP documentation.
> 
> You should *definitely* cite this one explicitly.

http://www.ntp.org/ntpfaq/NTP-s-algo.htm

A time difference of less than 128ms between server and client is required to maintain NTP synchronization. The typical accuracy on the Internetranges from about 5ms to 100ms, possibly varying with network delays. A recent survey[2] suggests that 90% of the NTP servers have network delays below 100ms, and about 99% are synchronized within one second to the synchronization peer.

(Worth noting as an upper range of what might be safely assumed)

> While I have no doubt
> it is there, that's not what people with untuned run-of-the-mill
> ntp systems encounter in the public Internet. (And I'm not sure
> it is really an upper bound either -- I don't think a 101ms error
> is appreciably less likely than a 99ms error?) And of course,
> people with finely tuned ntp systems easily achieve far better than 1ms.
> 
> [e-mail]
>  John Hawkinson