Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
On Wed, 14 Jun 2023 at 06:25, Richard Cochran wrote: > On Tue, Jun 13, 2023 at 01:01:11PM +0200, Erez wrote: > > > Just so I am clear on the matter. > > I simply suggest taking the same test you run with linuxptp-testsuite. > > And run it in a github action. So we can all run it before we send > patches. > > In addition to the tests you run :-) > > I run the tests _before_ I push anything to github. > Developers can and should run linuxptp-testsuite on their patches > before posting to the list. > That is good advice. Yet looking at the repositories, I can not tell which tests you actually run. Or which tests you expect me to run. > > You can add it into your pre-commit git hook, for example. > This is a good option developers can use. > > Once a commit lands in github, then it is too late. > > You can use github before, if you: 1. push the patch in a forked repository. 2. Open a new branch. for the github action. You can actually mark a github action to skip the master branch, as it is too late, as you say. The benefit of the github action is that we all can run the same test. Of course I can run many tests, but I can never be sure I run the same one you did. Running different tests is great, and yet, I think that a test we all run can benefit too. A regression test that tries to verify we did not break something that is working. Erez > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
Once a commit lands in github, then it is too late. Not really - if you push to a fork of linuxptp. Which, you, Richard, probably won't, but everybody else could. Martin -- Mgr. Martin Pecka, Ph.D. Researcher at Vision for Robotics and Autonomous Systems group Faculty of Electrical Engineering Czech Technical University in Prague Phone: +420 22435 7269 smime.p7s Description: Elektronicky podpis S/MIME ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Use messageLength field to detetmine suffix length
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
Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
On Tue, Jun 13, 2023 at 01:01:11PM +0200, Erez wrote: > Just so I am clear on the matter. > I simply suggest taking the same test you run with linuxptp-testsuite. > And run it in a github action. So we can all run it before we send patches. > In addition to the tests you run :-) I run the tests _before_ I push anything to github. Developers can and should run linuxptp-testsuite on their patches before posting to the list. You can add it into your pre-commit git hook, for example. Once a commit lands in github, then it is too late. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Use messageLength field to detetmine suffix length
Hi Erez, Thanks for the note. On Mon, 12 Jun 2023 21:14:17 +0200, Erez wrote: > This is not the only standard that follows the market and existing > products. > It happens everywhere. > I do not suggest to ignore standards, > Only bear in mind that we can not rely on others to implement the > standard to the letter. > And that standards in many cases involve politics of many vendors, > which lead to ambiguity by design and compromises. 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. My original email was not meant to be a full endorsement of the current implementation, but rather a justification for why it is technically reasonable. > Dylan. just one note. > The IEEE 802.3 standard actually follows an already existing Ethernet > protocol (Ethernet II). To add to this observation, since PTP utilizes the Ethernet II convention of using the length/type field in the frame as a type field rather than a length field, the expressed requirement is for the upper level protocol, in this case PTP, to have a mechanism for determining the length of the encapsulated message, if it is relevant. I would argue that the messageLength field was intended to be part of that mechanism for PTP, but I also agree that the standard doesn't actually prescribe its use. The mechanism currently in use is inference based on known possible payload sizes and known minimum frame sizes. This generally works, but it somehow feels less robust than using the messageLength field. I would argue that the messageLength field should not be considered redundant in the case of layer 2 links. I will say that some of the discussions in the archives seem to simultaneously talk about UDP and layer 2 transports in the same thread which somewhat confused my attempt at understanding everyone's position. >From my reading of IEEE 802.3, it doesn't sound like the standard wants to preclude future revisions from defining a larger minFrameSize parameter. After all, the minFrameSize parameter is defined per MAC data rate (IEEE 802.3 section 4.4.2). All currently defined MAC data rates use a minFrameSize of 64 octets, but it seems conceivable that in the future a faster data rate could require a larger minFrameSize. If this happened and the parameter grows beyond 67 bytes, the current implementation would discard those messages as bad messages. 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. If it makes sense to go down the path of requiring the transport layer to deliver specifically sized messages to the transport independent layer, then I would argue that any transport that does not explicitly communicate the size of its payload should read the PTP header and use the messageLength field to deliver only the relevant bytes to the upper layer. Finally, I wanted to comment on an exchange that I read before. On Fri, Feb 01, 2019, Richard Cochran wrote: > On Thu, Jan 31, 2019 at 04:22:20PM +, Geva, Erez wrote: > > For me, the only question is, if the Ethernet frame does have > > padding and the PTP frame is proper. > > Is there a problem? > > Yes, there is a problem. The length of the messages affects their > delay through network equipment. The PTP event messages are carefully > designed to all have the same length. You simply should not go > tacking random stuff onto the end of frames. While Richard's comment here may be true for messages that are forwarded through network equipment, not all profiles actually allow this to happen. For example, within 802.1AS there are only PTP Relay Instances and PTP End Instances. Frames are not "forwarded" through network equipment. Rather, they are "relayed" with corrections for their exact residence time in said equipment. 802.1AS defines the message timestamp points precisely. For example, the media-dependent layer specification for full-duplex point-to-point links requires the following. 802.1AS-2020 section 11.3.9 - Event message timestamp point: The message timestamp point for a PTP event message shall be the beginning of the first symbol following the start of frame delimiter. 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. -Dylan ___ Linuxptp-devel mai
Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
On Tue, 13 Jun 2023 at 12:57, Erez wrote: > > > On Tue, 13 Jun 2023 at 09:48, Richard Cochran > wrote: > >> On Tue, Jun 13, 2023 at 08:02:29AM +0200, Erez wrote: >> > Hi, >> > >> > Using Miroslav's linuxptp-testsuite we can run a simulated HIL in github >> > itself. >> >> "Simulated HIL" is an oxymoron. H stand for hardware. >> > > Simulation of hardware, to be more correct :-) > > >> >> Don't get me wrong, I absolutely love linuxptp-testsuite, and I run it >> on every single patch. >> >> But simulation and actual hardware are two different worlds. >> > > Sure, I do not suggest skipping real hardware. By no means. > Yet automatic testing has benefits, especially regression tests. > > Just so I am clear on the matter. I simply suggest taking the same test you run with linuxptp-testsuite. And run it in a github action. So we can all run it before we send patches. In addition to the tests you run :-) Erez > Erez > > >> Thanks, >> Richard >> > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
On Tue, 13 Jun 2023 at 09:48, Richard Cochran wrote: > On Tue, Jun 13, 2023 at 08:02:29AM +0200, Erez wrote: > > Hi, > > > > Using Miroslav's linuxptp-testsuite we can run a simulated HIL in github > > itself. > > "Simulated HIL" is an oxymoron. H stand for hardware. > Simulation of hardware, to be more correct :-) > > Don't get me wrong, I absolutely love linuxptp-testsuite, and I run it > on every single patch. > > But simulation and actual hardware are two different worlds. > Sure, I do not suggest skipping real hardware. By no means. Yet automatic testing has benefits, especially regression tests. Erez > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
On Tue, Jun 13, 2023 at 08:02:29AM +0200, Erez wrote: > Hi, > > Using Miroslav's linuxptp-testsuite we can run a simulated HIL in github > itself. "Simulated HIL" is an oxymoron. H stand for hardware. Don't get me wrong, I absolutely love linuxptp-testsuite, and I run it on every single patch. But simulation and actual hardware are two different worlds. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
