Re: [Ntp] Frequency transfer in NTP

[Miroslav Lichvar <[e-mail]>]

On Mon, Feb 01, 2021 at 01:18:15PM +0100, Magnus Danielson wrote:
> On 2021-02-01 12:38, Miroslav Lichvar wrote:
> > 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.

That would be great.

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

I think the response to a large time/frequency step indicates how well
it will perform in a chain. You can scale it down to any numbers you
like. In normal operation there are smaller offsets, but the response
is identical in proportion. It's a series of responses that add up,
together with the frequency errors coming from the clock drift and
measurement noise due to network jitter.

As for long term errors, I have some data for chrony:

st	no-freq		freq
2	11.7		12.0
3	18.1		15.4
4	24.7		17.2
5	30.1		20.7
6	40.1		22.5
7	50.4		25.9
8	64.2		26.9
9	77.1		29.0
10	91.7		31.4

It is the RMS offset (in microseconds) at different strata of the
chain. As you can see, the error grows much faster without frequency
transfer. At stratum 10 it's already 3x better.

If I slowed down the loop as you suggest, the error would not grow as
quickly, but it would start at a larger value.

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

Ok, just specify the conditions. A simulation is fine. To show the
impact of independent frequency transfer, I'm mostly interested in the
case where frequency errors dominate noise in measurements, i.e. when
the Allan intercept is too short for the polling interval. Let's say a
polling interval of 64 seconds, a network jitter of 10 microseconds
and a random walk of 1 ppb/s for the clock?

-- 
Miroslav Lichvar