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

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 <ntp-bounces@ietf.org> on behalf of Daniel Franke 
> <dfoxfranke@gmail.com>
> Sent: Monday, April 13, 2020 1:09 PM
> To: Watson Ladd <watsonbladd@gmail.com>
> Cc: NTP WG <ntp@ietf.org>
> 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 <dfoxfranke@gmail.com> 
> 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 <watsonbladd@gmail.com> 
>> wrote:
>>>
>>>
>>>
>>> On Mon, Apr 13, 2020, 7:21 AM Daniel Franke <dfoxfranke@gmail.com> 
>>> wrote:
>>>>
>>>> On Sun, Apr 12, 2020 at 6:11 PM Watson Ladd <watsonbladd@gmail.com> 
>>>> 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
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp