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

[Doug Arnold <[e-mail]>]

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