Re: [Ntp] The bump, or why NTP v5 must specify impulse response

[Harlan Stenn <[e-mail]>]

We had the same discussion at the transition from ntpv3 to ntpv4.

If you do this, please do not call it NTP.  Please find another group to
do this in, perhaps TICTOC.

H

On 4/14/2020 4:19 AM, Dieter Sibold wrote:
> I think the document which specifies the new NTP protocol should not
> consider the clock steering algorithm as Doug suggest. But we should
> start a second document in which we describing at least one possible
> steering algorithm. This might only be informational.
> 
> Dieter
> 
> On 13 Apr 2020, at 23:22, Doug Arnold wrote:
> 
>> I think that the most important thing for the clock steering algorithm
>> in ntpv5 is that it is modular.  Define an interface to the clock
>> steering subsystem so that people can make servo loop filters
>> specialized for a specific set of conditions.
>>
>> If we define a default clock steering algorithm, the most important
>> property is that it always converges, even if it is not the most
>> accurate for any specific network conditions.  It probably has to be
>> fairly simple to have this property.  Complex algorithms usually have
>> weird corner cases.
>>
>> As for Kalman filters, they work really well for things like GPS
>> receives where the noise properties are relatively constant.  Then you
>> can tune them for those noise properties.  Queuing noise in a network
>> varies wildly, and is often exhibits a highly skewed client clock
>> error measurement probability density with a peak near zero followed
>> by a long tail in one direction.  I suspect that Kalman filters will
>> perform poorly on highly skewed data unless you have a non-linear
>> prefilter to make the noise probability density closer to gaussian.  I
>> know of people who have gotten good results for PTP servo loops using
>> Kalman filters, but with a generalized luckly packet prefilter to
>> eliminate the long tail in the distribution, and with the prefilter
>> also determining the Kalman filter parameters.  That is a complicated
>> algorithm which probably has some catastrophic corner cases, so it
>> wouldn't be a good candidate for a default servo loop which always
>> works at least ok.
>>
>> Doug
>>
>> ________________________________
>> From: ntp <[e-mail]> on behalf of Daniel Franke
>> <[e-mail]>
>> Sent: Monday, April 13, 2020 1:09 PM
>> To: Watson Ladd <[e-mail]>
>> Cc: NTP WG <[e-mail]>
>> Subject: Re: [Ntp] The bump, or why NTP v5 must specify impulse response
>>
>> What motivates my skepticism here, by the way, is a belief that it's
>> possible to get much, much better performance with better
>> synchronization algorithms. A number of academic researchers have
>> experimented with Kalman filters [1][2][3] and gotten phenomenal
>> results, in the case of [1], two orders of magnitude better than stock
>> ntpd 4.2.0. I suspect that this could be even further improved with
>> more accurate network models (Kalman filters would be provably optimal
>> if network jitter were Gaussian, but we all know it isn't). I want to
>> avoid specifying any requirements that would discourage or obstruct
>> this sort of research from being developed into production
>> implementations.
>>
>> [1] https://ieeexplore.ieee.org/abstract/document/4268082
>> [2] http://alumni.media.mit.edu/~aggelos/papers/tuffc_nov04.pdf
>> [3] https://www.sciencedirect.com/science/article/pii/S1474667015361358
>>
>> On Mon, Apr 13, 2020 at 3:24 PM Daniel Franke <[e-mail]>
>> wrote:
>>>
>>> I don't think I follow. In what sense does it limit the length of the
>>> chain, other than that stratum is capped at 16? And what
>>> characteristic of RFC 5905's recommended input response address the
>>> problem? (I need to read the book you've referenced before I fully
>>> understand the problem in the first place; I've ordered it but it'll
>>> take some time to arrive).
>>>
>>> On Mon, Apr 13, 2020 at 3:15 PM Watson Ladd <[e-mail]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Apr 13, 2020, 7:21 AM Daniel Franke <[e-mail]>
>>>> wrote:
>>>>>
>>>>> On Sun, Apr 12, 2020 at 6:11 PM Watson Ladd <[e-mail]>
>>>>> wrote:
>>>>>> Section 14.5 of Phase Lock Techniques by Floyd Gardner describes
>>>>>> difficult problems caused by the accumulation of errors in a chain of
>>>>>> PLLs under benign conditions, and section 2.2.4 describes the root
>>>>>> cause, namely an inevitable peak in the transfer function of a second
>>>>>> order filter. I don't think these are insolvable in NTP v5, but they
>>>>>> should give pause to the idea that we can avoid needing to specify
>>>>>> the
>>>>>> the synchronization algorithm. The peaking of the PLL needs to be
>>>>>> controlled, or some thing more complex needs to be specified.
>>>>>
>>>>> Are the algorithms in RFC 5905 vulnerable to this? If so, I think that
>>>>> shoots down any implication that it's a practical necessity to solve
>>>>> this in the NTPv5 spec, since we've obviously been getting by okay so
>>>>> far.
>>>>
>>>>
>>>> v4 limits the length of the chain and specifies the input response
>>>> to have, which solves the problem.
>>>>
>>>>>
>>>>> Just to be clear, though, I'm not proposing that the WG should be
>>>>> *silent* on synchronization algorithms in v5. Just that whatever we
>>>>> have to say about it should be in a separate, Informational document,
>>>>> and can discuss the design space and suggest multiple possibilities
>>>>> rather than require one particular thing.
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!