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

[Miroslav Lichvar <[e-mail]>]

On Mon, Apr 13, 2020 at 09:22:33PM +0000, Doug Arnold wrote:
> 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.

Simple algorithms may not be useful in real-world applications.
Complex algorithms are difficult to analyze and show that they always
work in given conditions. I'm not sure how much sense it makes for the
draft to have some general requirements.

I'd like to see an example of the issue with a long chain of PLLs. If
anyone has a code of a susceptible PLL, I can try to simulate a long
chain.

> 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.

In the context of NTP, which is supposed to synchronize computer
clocks, the clock may be an even bigger problem than the network.
Without a good model of the clock a Kalman filter (at least in the
basic form) cannot perform well. The problem is in random changes in
the frequency of the clock due to temperature changes (due to random
changes in the load of various components in the computer). A Kalman
filter that works well on an idle computer won't likely work well on a
moderately loaded server. It would need to include data from a
temperature probe. Making the loop adaptive is not that easy. In NTPv3
and NTPv4 it is done by adjusting the polling interval (to which is
tied the PLL/FLL time constant).

-- 
Miroslav Lichvar