On Tue, Jun 13, 2023 at 12:57:10PM -0400, Dylan Robinson wrote: > Definitely. In the audio space where I work there are many examples of > this. I have seen how being first to market and having wide adoption can > end up turning "improper" implementations into a de facto standard. > Based on my reading of the archives, however, it does not sound like > there is a desire to support such impropriety when it comes to padding.
Correct. > Given that a feature of the Linux PTP Project is a "modular design > allowing painless addition of new transports", I think there either > should be clarification in the form of documentation or code comments of > what is expected to be delivered from the transport layer in terms of > payload length, or the transport independent layer should be able to > handle receive buffers with various amounts of trailing padding. 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.) > 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. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
