On Fri, Aug 18, 2023 at 12:31:47PM +0200, Maciek Machnikowski wrote:
> Current implementation saves s->drift as an offset between current clock
> frequency and the remote clock frequency calculated on first two samples.
> 
> Locked state of the PI servo assumes the s->drift holds the history
> of clock frequency difference scaled by s->ki * weight.

s->drift is the drift of the uncompensated clock. It's not supposed to be
scaled by anything.

> As a result the lock needs more time to stabilize when the frequency
> offset is very large (ex. set to extreme values with phc_ctl) or may
> totally prevent servo from correctly locking.

How exactly did you test it? Have you tried it with the P2P delay
mechanism?

I suspect you are trying to compensate for the error in E2E delay
measured before the frequency is corrected. I think a proper fix would
be to adjust the timestamps from E2E and recalculate the delay before
stepping the clock.

> This patch fixes the s->drift when entering the stable state to hold
> the scaled drift.

That looks wrong to me and in my test with a clock which has a large
frequency error it performs worse.

-- 
Miroslav Lichvar



_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Reply via email to