On Tue, 13 Jun 2023 21:39:25 -0700, Richard Cochran wrote:
> No, no, no.
>
> The only reason people are wanting random padding is because their
> hardware design is broken. There is no excuse for that.
>
> As a non-standard extension to the standards, we ALREADY generously
> allow two extra bytes for checksum correction.
>
> (Tacking on suffixes between PHY/MAC and device driver are
> unproblematic, because the driver can remove the offending cruft.)
Richard, based on what I have read before and this response I can tell
that you have a misunderstanding of what is actually going on with the
layer-2 transport. I am not talking about broken hardware or checksum
correction. I am talking about how Media Access Controller (MAC) clients
actually work. The raw transport in this project becomes a MAC client
when it opens a raw layer-2 socket. This means that we are GUARANTEED
to see MAC sublayer appended padding.
There is nothing "non-standard" about this padding here. In fact it is
fully REQUIRED by the standard. Layer-2 Ethernet links make no explicit
guarantees about the lengths of packets delivered to MAC clients when
the type/length field is used as a type field. PTP uses a type value
of 0x88f7 here. Since this value is greater than or equal to 1536
decimal, it becomes the responsibility of the MAC client to operate
properly when the MAC sublayer pads the supplied MAC client data.
802.3-2022 section 3.2.6:
It is the responsibility of the MAC client to ensure that the MAC
client operates properly when the MAC sublayer pads the supplied MAC
Client data
I'll reiterate, since there is no client data length information
available at the data link layer, the MAC cannot remove padding. Only a
MAC client that understands the protocol being communicated can remove
padding.
I don't think you are appreciating how low level this transport actually
is, when a linuxptp instance sends a 44 byte sync message using the
layer-2 transport a linuxptp receiver instance will always receive a
46 byte sync message (assuming this message goes on a wire). This is
because the MAC sublayer will always append padding to meet the
minFrameSize requirement of data rate of the physical layer.
The fact that you describe dealing with this required padding as being
"generous" is confusing to me.
> > Since the message is timestamped at the beginning of the frame,
> > superfluous padding on layer 2 links shouldn't really affect
> > protocol performance aside from utilizing unnecessary bandwidth.
>
> It affects the residence time, and that can affect synchronization
> quality.
I can't speak for all profiles, but I have been working on and with
802.1AS end stations and relays for some time. The biggest contributor
to residence time, by far, is the software stack that is running in the
relay. PTP relay instances that run on top of Linux typically see
milliseconds of residence time due to software scheduling latencies and
driver performance. 802.1AS Relay instances with bare metal software
stacks can see residence times in the tens of microseconds.
Interestingly, even though some devices have residence times over 1000x
longer than others, we see no synchronization quality issues. Messages
are timestamped on ingress and on egress at a precise location. The
timestamp points are at the beginning frames such that REQUIRED trailing
padding does not affect sync accuracy. Really, the biggest issue we see
with sync accuracy in 802.1AS has to do with improper PHY ingress and
egress latency compensation, because it is not always specified by PHY
manufacturers.
The relay devices that MOTU sells and I work on will accept frames with
trailing padding and transmit frames without it. This trailing padding
creates no issues in our devices, and as such we have customers buy them
to work around this "feature" of linuxptp. So really it is better for us
to leave the fragile implementation in place.
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
