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

[Daniel Franke <[e-mail]>]

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.