On Wed, 5 Jun 2019 at 20:50, Vladimir Oltean <olte...@gmail.com> wrote: > > On Wed, 5 Jun 2019 at 20:45, Richard Cochran <richardcoch...@gmail.com> wrote: > > > > On Wed, Jun 05, 2019 at 02:33:52PM +0300, Vladimir Oltean wrote: > > > In the meantime: Richard, do you have any objections to this patchset? > > > > I like the fact that you didn't have to change the dsa or ptp > > frameworks this time around. I haven't taken a closer look than that > > yet. > > > > > I was wondering whether the path delay difference between E2E and P2P > > > rings any bell to you. > > > > Can it be that the switch applies corrections in HW? > > > > Yes it can be. It was one of the first things I thought of. > Normally it updates the correction field with its own residence time > in 1-step L2 event messages (but I use 2 step). > It also has a bit called IGNORE2STF (ignore 2-step flag) by which it > updates the correction field in all L2 event messages (including sync, > thereby violating the spec for a switch, as far as I'm aware). But I'm > not setting it. > I also looked at egress frames with wireshark and the correction field is > zero. >
I also changed around the values of ptp_dst_mac and p2p_dst_mac in linuxptp in the hope that I'd throw off whatever hardware parser it has to identify the event frames, but I still get negative path delay with E2E nonetheless. So it's probably not that. > > Thanks, > > Richard > > Thanks, > -Vladimir -Vladimir