On Thu, 30 May 2019 at 17:30, Richard Cochran [off-list ref] wrote:

On Thu, May 30, 2019 at 12:01:23PM +0300, Vladimir Oltean wrote:

quoted

In fact that's why it doesn't work: because linuxptp adds ptp_dst_mac
(01-1B-19-00-00-00) and (01-80-C2-00-00-0E) to the MAC's multicast
filter, but the switch in its great wisdom mangles bytes
01-1B-19-xx-xx-00 of the DMAC to place the switch id and source port
there (a rudimentary tagging mechanism). So the frames are no longer
accepted by this multicast MAC filter on the DSA master port unless
it's put in ALLMULTI or PROMISC.

IOW, it is not linuxptp's choice to use these modes, but rather this
is caused by a limitation of your device.

Didn't want to suggest otherwise. I'll see how I'm going to address that.

quoted

If the meta frames weren't associated with the correct link-local
frame, then the whole expect_meta -> SJA1105_STATE_META_ARRIVED
mechanism would go haywire, but it doesn't.

Not necessarily.  If two frames that arrive at nearly the same time
get their timestamps mixed up, that would be enough to break the time
values but without breaking your state machine.

This doesn't exactly sound like the type of thing I can check for.
The RX and TX timestamps *are* monotonically increasing with time for
all frames when I'm printing them in the {rx,tx}tstamp callbacks.

quoted

I was actually thinking it has something to do with the fact that I
shouldn't apply frequency corrections on timestamps of PTP delay
messages. Does that make any sense?

What do you mean by that?  Is the driver altering PTP message fields?

No.
The driver returns free-running timestamps altered with a timecounter
frequency set by adjfine and offset set by adjtime.
I was wondering out loud if there's any value in identifying delay
messages in order to not apply this frequency adjustment for their
timestamps.

-Vladimir

Thanks,
Richard