Re: [Ntp] Frequency transfer in NTP

[Magnus Danielson <[e-mail]>]

Hi Miroslav,

On 2021-01-28 15:31, Miroslav Lichvar wrote:
> One of the new features that was proposed for NTPv5 is an additional
> receive timestamp to enable a frequency transfer to stabilize
> synchronization. I have tested this idea with two different
> implementations:
>
> https://fedorapeople.org/~mlichvar/ntp-freq-transfer/
>
> I think this would be a significant improvement of the protocol.
>
While I think there is room for improvements in NTP, I remain skeptic
about this one.

First of all, I see many issues with the implementations as you use as
your reference settings. The fact that they are poorly tuned to be
creating overshot is a tell-tale. In the frequency domain, each of the
PLLs will have significant "jitter peaking" (this is a searchable term
for relevant articles and books). Jitter peaking creates an increased
positive gain for each step at the same frequency as you progress down
the chain, and your time-domain plots illustrates the same fact just
perfectly. The first PLL loop will feed the "worst case" input into the
next where it will amplify it most, and so it goes. The problem is
already well analyzed classically, and what you need to do is to
increase the damping factor, and hence reduce Q, of the PLL and this is
done by increase the P factor of a PI-loop PLL.

So, you need to do this up front to be meaningful as reference. That you
didn't will show off in a tell-tale that I will come back to.

You also use a statement that you cannot in the protocol convey both
time and frequency errors. This is just plain incorrect. A phase
measurement will include both. A static phase error read will be that
phase error. A phase ramp will be the tell-tale of a frequency
difference. What you do in a PI-loop is that you scale the phase
difference measure through the P and I factors and then the I part hits
an integrator and then the output of that is summed by the phase scaled
by the P factor. For simplicity let's assumed that the loop have locked.
When it has locked, the loop as changed state such the integrator in the
PI regulator holds a state that reflects the frequency error, just
around where it needs to be as it steers the frequency of the oscillator
to keep the phase ramp of the source and phase ramp of the steered
oscillators on average alined. Any DC component out of the phase
detector would drive the integrator towards achieving the balance. The I
scaling factor is proportional to the square of the PLLs resonance
frequency. Now, as locked, the DC part of the phase error is driven to
zero, so what remains is the variations around the balance, and that AC
goes though the P factor which scales this in steering the oscillator.
The P factor will be proportional to the resonance frequency and the
damping factor. Increase P and you reduce the fluctuations. Reduce P and
you increase them, in fact as you drive it towards zero you go towards a
sine-oscillator.

Now, the resonance frequency I mentioned will also be the frequency of
the jitter peaking, and the gain at that will always be positive, and a
factor of the Q/d/P chosen. So, as you increase Q (that is decrease
damping d and factor P) the jitter peaking goes up. A rule of thumb, and
this is from memory, is that you want to keep jitter peaking below 0.25
dB, requiring a damping factor being 3 or higher. The over-shots you see
already on a single link tells me you have an underdamped system, that
is Q > 1/sqrt(2). You want to be in the overdamped system.

Now, I did not cover how the PI-regulator achieves lock, and that is
because you can easily consider this a messy nonlinear thing, chaotic to
the untrained eye. Turns out that if you just let it, a PI-loop will
always lock. Without going into too much messy details, it turns out you
need to go through the loop twice, once through the AC path and once
through the DC path to understand how the beat-notes will make the
integrator of the PI to move in the right direction. Once it is
sufficiently close, the remaining frequency and phase error is small
enough for it just to decay without loosing cycles. Lack of those AC
cycles is classically used to indicate the lock of the loop.

Can we improve this? Well, we could either do a frequency estimator or
go to full PID loop controller. I did this. The frequency error produces
a linear phase-ramp in the phase data. Now, as we derive that to get the
slope, we do get the derive path for the D in the PID. Turns out that
any other frequency estimator achieves the same basic processing. Fine,
but let's analyze that and balance it. To my great surprise, it turns
out that my P and D factors just add on top of each other in a PID PLL.
It's just the same. Also, a similar thing has been analyzed in a
mechanism called injection locking, at which the input frequency of a
signal will "pull" and oscillator to it. That also turns out to shift
the damping of the oscillator.

So, as you do this, all you end up doing is create a more complex way to
sett your damping factor and hence P. It will not be very helpful for
your understanding of the dynamics of the system. That you was able to
go from overshooting and thus under-damped to a more well-behaved
damping is because you ended up doing exactly this, alter the damping
factor. Your starting point of was very good to illustrate the effect,
but not very representative to what it should be. Actually, you should
go from boring response to even more boring response.

No need to get dizzy over the Fokker-Plank graphs, always something.

I have before mentioned that incorrect setting of parameters compared to
polling rate will create overshoots. This is because P and I parameters
needs to be scaled correctly with regards to the polling rate, or else
the balance between them will alter the actual damping factor and thus
going from over-damped to under-damped.

So, what I see with my experience is not a problem with the protocol,
but a problem with the implementations. I think those should be
addressed first, before going into considering changes to the protocol
making it more complex, especially as it may not be needed.

Sorry if this discourage you, but I did the exercise and ended up
learning, so I just want to share some experience and help getting
things towards the right direction.

I can provide a range of references, unfortunatly not all in online
sources. I could do a fairly long derivation of equations for it, and
you can find posts from me where I do that.

I would recommend that we do not progress further with this ID until the
issues I've pointed out have been addressed and we look at the reminding
benefit, if any, for the ID.

Cheers,
Magnus