This should be discussed at linuxptp-devel. On Wed, May 04, 2022 at 11:39:19AM +0000, Oleg Obleukhov wrote: > >> I implemented a quick patch > >> https://gist.github.com/leoleovich/5a4dff7e089bd429c5d208d9276e1683 which > >> can mitigate this and it works very well: > > > >> Preventing unnecessary tuning of the servo for a short period of time by > >> using a padding technique (simply filling with previous values). > The patch I proposed simply doesn’t pass the offset to a servo - so it > shouldn’t be too bad. For example with default ptp4l settings we can tolerate > several missed syncs in a row. But I am open for suggestions of course.
I think the default configuration of the PI servo can tolerate only one missed update at a time. If you repeatedly drop two samples and pass one, it will be unstable and oscillations will grow until it is updated at a higher rate. However unlikely that would be to happen in real world, your patch doesn't seem to prevent that. > > That patch seems to be dropping the sample and there is a different > > output shown in the example. Is there a newer version of the patch you > > didn't publish? > The code I suggested matches the output. It simply prints something like: > skip 1/2 large offset (>20000) -248483 > When occasional spikes arise. The only difference is max_offset_locked and > max_offset_locked_skip should be set to 0 and currently they are at 20000 > and 2 respectively. The example output posted here didn't have the SYNCHRONIZATION_FAULT messages, so I assumed you were doing something with the servo. -- Miroslav Lichvar _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
