Hi Miroslav, Thank you very much for your clear explanation. I now understand why peer_delay_req needed to be set to NULL when clock jumping(to avoid the corruption of delay measurement)
But I have another problem now, With ptp4l.max_frequency limited to 1,000,000(to avoid PHC big jumpping after first offset setting) When this occured, PHC can only approching master very slowly(the clock servo enters LOCK state) 1. after the first clock jumpping, PHC jumpped to master, SYS keep the original value 2. peer_delay_req set to NUL 3. when the next peer_delay_resp arrives, the port enters the faulty state, which cause the port reinited(PHC reset to SYS) 4. then the next SYNC, FUP arrives, the clock.servo enter LOCK state, Do you have any suggestions to fix this problem? Or do I need to change my ptp4l configuration? thank you Miroslav Lichvar <mlich...@redhat.com> 于2023年3月15日周三 16:03写道： > On Wed, Mar 15, 2023 at 03:48:41PM +0800, merlinhe wrote: > > Hello Team, > > > > I recently encountered a *rogue peer delay response* error which seemly > > caused by function port_synchronize() reset peer_delay_req pointer. > > I'd like to know why port_synchronize() reset p->peer_delay_req to NULL > is > > needed, can i comment this to avoid the rogue peer delay response error? > > The clock jumping in the middle of a peer delay measurement corrupts > the result. Pretending there was no request is a simple solution to > avoid accepting the response, although the error message is confusing. > > -- > Miroslav Lichvar > >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
