On 4/29/2021 8:04 AM, ramesh t wrote: > hello Jake, > > Did time profiling using time ticks. > Under the problem condition, observing clock_gettime of interface > connected to BC is taking more time ticks. This results in phc offset > jumping to 4 digit value momentarily. Also i'm not sure if reading > across numa is triggering this issue. >
Not sure I follow here. You mean BC as in the boundary clock you're connected to? > Please suggest a way to fix in the phc2sys offset code? > 1) Should we prevent update on phc2sys value if there is momentarily jump? > You could possibly filter or average the delay to remove outliers, but I am not sure how this impacts things. Other experts on this list are probably better to answer that. To me, it sounds like the issue is that in some cases the DELAY_REQ packet is actually taking longer in one case. You might also try peer delay instead if your network setup supports it? > Please suggest. > > Thanks for your support on this issue. > > Regards, > Ramesh > On Thursday, April 29, 2021, 07:33:49 AM GMT+5:30, ramesh t via > Linuxptp-users <linuxptp-us...@lists.sourceforge.net> wrote: _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
