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