Re: [Ntp] Frequency transfer in NTP

[Magnus Danielson <[e-mail]>]

Miroslav,

On 2021-02-01 12:38, Miroslav Lichvar wrote:
> On Mon, Feb 01, 2021 at 12:00:50PM +0100, Magnus Danielson wrote:
>> On 2021-02-01 10:37, Miroslav Lichvar wrote:
>>> On Sun, Jan 31, 2021 at 11:30:03PM +0100, Magnus Danielson wrote:
>>> Yes, you can dampen the loops to avoid the overshoot, but that will
>>> have a negative impact on the timekeeping performance. You can
>>> minimize the phase error, or frequency error, but not both at the same
>>> time.
>> Turns out that as you measure the phase stability in MTIE and TDEV, as
>> well as frequency stability in ADEV, you need to remove that overshot /
>> resonance for best stability. This becomes especially true as you build
>> a chain of them, as it will grow worse along the chain.
> Right. You cannot minimize the phase error upper in the chain without
> disturbing the clocks furher down in the chain. A sacrifice needs to
> be made to keep the chain stable unless the frequency is transfered
> separately. That's what I tried to explain in the post.

Once the phase error is small enough, other performance characteristics
tend to dominate, such as frequency stability (which is ADEV for random
noise and MAFE for systematic noise) and phase stability (which is TDEV
for random noise and MTIE for systematic noise). Turns out it works
really well in practice to get very low offsets doing this, as this is
what I've spent a very long time to perfect. You did not really achieve
the goal in the post as it lacked a number of considerations that I
tried to point out.

Also, the overshots tends to extend the time before equilibrium is
achieved, so it takes longer time to get that stable offset.

>
>> While extremely simple, difficult to tune has not been my experience.
>> Once one have done once gain scaling right, properly orthogonal setting
>> of damping and frequency have been straight-forward. Getting optimum
>> performance given a certain condition is as always a bit tricker, but
>> not impossible.
> The tricky part is making it adaptive. It's easy to tune a PI loop for
> a well-characterised clock and network, but making it work well over a
> wide range of conditions, as is common in NTP, is hard.
For sure. That's why you end up having to consider adaptive filters.
However, that adaptive filter needs to respect the basic rules
regardless, so one needs to get the resonance part right to start with
and only then one make it auto-tuneable. Those is orthogonal properties.
The PI loop is sufficient to understand the basic. We then only want to
tune the frequency for best cut-over between link noise and local
oscillator noise (and drift).
>
>>> If you wanted to be constructive, it would be best if you showed us an
>>> example of a loop that doesn't overshoot in the step response and
>>> otherwise performs similarly to ntp or chrony.
>> I could provide an example of scaling with poll-rate, sure. I just don't
>> have the setup to do measurement of a chain, so that would take time and
>> effort that I might not be able to pull together, but others may have that.
> I'd like to see an example of a loop (it doesn't have to be PI) that
> performs similarly or better than an implementation using the proposed
> frequency transfer. I don't think that is possible. You say it is, so
> an example would be a good way to show that.

Let me see if I can whip up a little simulator for you then. I've done
that before and made it match up with the reality just nicely.

There is one thing you can do to improve things, but it does not involve
frequency but rater phase. That's where the is place for possible
improvements in my mind. I also said that before we can look at
benefits, we need to fix the basic problems of the setup. Only after
that we can measure things, and I did point out that frequency aiding
alters the damping factor and hence the reason we see damping factor
improvements, but the initial damping factor was way of what it should
be for a chain network, so it is not relevant comparison. If I do an
effort, you will have to do one where you fix your extremely unfair
comparisons, as you end up not proving improvement over know good
situation. What you have ends up being meaningless comparison for me, it
needs to start from a well-tuned setup and then show further improvements.

Also, what you show is transient behavior, not long-term errors, not the
usual measure of stability. You need to do that. My experience is that
transient behaviors needs to be taken way down, and first things to fix
is damping. Once damping, and associated scaling with polling rate is
done, only then it becomes meaningful to consider fine-tuning of
frequency which is the adaptive filter trap. However, even a
non-adaptive setup should not be too bad, and the chain problems show up.

I recommend you to look at TimeLab and Stable32 for analysis. Stable32
you can download for free from IEEE UFFC, it used to be a commercial
software.

>
> Just post the code of the loop. In any language you like. I can
> integrate it with NTP and compare it with the existing
> implementations.
>
Notice that no "code" will just work as you drop it in. The gain factors
needs to be corrected for any implementation. Building code to tune that
is more or less painful depending on the implementation. Things needs to
be normalized and parametrized for this to have a chance of working. I
don't have time to make it fool proof.

Cheers,
Magnus