On Fri, Jun 16, 2023 at 06:21:57PM -0400, Dylan Robinson wrote:
> I feel bad for how I communicated.
np, I also want to apologize because after re-reading the thread, I
was indeed projecting an "ulterior motive" onto your posts.
Your summary of the different standards is helpful, and I think it
On Thu, 15 Jun 2023 19:13:39 -0400, Dylan Robinson wrote:
> If a problem isn't apparent after everything already discussed, then
> further discussion is not necessary.
Hi Richard,
I feel bad for how I communicated.
After reflection and research, I realize that I should not have
questioned your u
On Thu, Jun 15, 2023 at 05:02:14PM -0400, Dylan Robinson wrote:
> I don't think I'm conflating these things and the problem exists merely
> with properly padded packets. I have been trying to discuss how best to
> be a robust IEEE 802.3 MAC client by examining the standards documents.
I claim that
On Thu, 15 Jun 2023 12:28:10 -0700, Richard Cochran wrote:
> You conflate two things:
>
> Padding a frame to the minimum length is one thing.
>
> Tacking on random proprietary cruft is quite another.
>
> The former in no way justifies the latter.
I don't think I'm conflating these things and the p
On Wed, Jun 14, 2023 at 11:48:11AM -0400, Dylan Robinson wrote:
> 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 mes
On Thu, Jun 15, 2023 at 07:49:58AM -0400, Dylan Robinson wrote:
> 4. Enable fcs reception using the following command.
There is no use case for enabling fcs. Really.
(no) Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforg
Here is a very simple test that can be done to demonstrate the issue
with the current implementation.
1. Connect ethernet to a 802.1AS grandmaster that will win bcma.
2. Start ptp4l on interface with gPTP.cfg configuration file and
stdout logging.
3. Notice everything working fine (no bad mess
On Wed, 14 Jun 2023 11:48:11 -0400, Dylan Robinson wrote:
> 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).
A small clarification to my previous mes
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
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 re
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
> sta
On Mon, 12 Jun 2023 at 20:04, Dylan Robinson
wrote:
> On Sun, 11 Jun 2023 15:42:23 -0700, Richard Cochran wrote:
> > NAK. Please consult the mailing list archives.
>
> Oops, I can see that this has already been discussed extensively! It
> makes sense that this change isn't necessary. I had to do
On Sun, 11 Jun 2023 15:42:23 -0700, Richard Cochran wrote:
> NAK. Please consult the mailing list archives.
Oops, I can see that this has already been discussed extensively! It
makes sense that this change isn't necessary. I had to do some reading
to convince myself, so I'll include what I found.
On Sun, Jun 11, 2023 at 05:51:40PM -0400, Dylan Robinson wrote:
> Use the messageLength header field, rather than the number of bytes
> received from the transport layer, when determining the length of the
> suffix. Check to make sure the transport layer delivered at least
> messageLength number of
Use the messageLength header field, rather than the number of bytes
received from the transport layer, when determining the length of the
suffix. Check to make sure the transport layer delivered at least
messageLength number of bytes, but do not discard messages if additional
bytes are received. Ce
15 matches
Mail list logo
