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
ques
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
padding and it shall leave the data field of the MAC frame intact.
Also more corrections to my previous email:
On Wed, 14 Jun 2023 11:48:11 -0400, Dylan Robinson wrote:
> The relay devices that MOTU sells and I work on will accept frames
> with trailing padding and transmit frames without
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
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
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 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.
. Certain transports, such as raw ethernet, may add
and deliver additional padding bytes to the application. It is therefore
not safe to assume that all delivered bytes belong to the message.
Signed-off-by: Dylan Robinson
---
msg.c | 23 +++
1 file changed, 11 insertions(+), 12
On Wed, 7 Jun 2023 17:26:08 +0200, Erez wrote:
> Hi,
>
> We tie patches by using the version, so version 2 is named: "[PATCH v2]"
> We use "git format-patch -v2"
> And add "--cover-letter" in case of several commits.
>
> Next time :-)
>
> Erez
Hi Erez,
Understood. Thank you for letting me know.
On Tue, 6 Jun 2023 14:24:20 -0400, Dylan Robinson wrote:
> I guess what this all is trying to convey is that since peer delay
> messages from a non-zero clock domain, are required to be invoked on
> domain 0 when their transportSpecific value is 1, if we see a non-zero
> domain numb
non-zero correction fields based on the 802.1AS equation as well as MOTU
audio interfaces that don't utilize the correction fields.
Signed-off-by: Dylan Robinson
---
msg.h | 3 +++
port.c | 8 +++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/msg.h b/msg.h
index cb
Hi Maciek,
Thank you for the feedback.
On Tue, 6 Jun 2023 10:02:40 +0200, Maciek Machnikowski wrote:
> Can we do the #define for that instead of (1<<4)?
Yes, I can do that.
> Why we require clock domain to be 0? AFIK the 802.1AS-2020 added
> support for multiple domains.
> Also the comment tal
based on the KSZ9567 with
non-zero correction fields based on the 802.1AS equation as well as MOTU
audio interfaces that don't utilize the correction fields.
Signed-off-by: Dylan Robinson
---
port.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/port.c b/p
On Fri, 2 Jun 2023 11:27:53 -0700, Richard Cochran wrote:
> I think the standard does indeed have a bug. It shouldn't have
> contradicted 1588 in the first place.
Yeah, that's fair, it shouldn't have happened.
In any case, to support the contradiction, I think the following proof
of concept wou
On Thu, 1 Jun 2023 15:13:31 -0400, Dylan Robinson wrote:
> On Thu, 1 Jun 2023 06:34:19 -0700, Richard Cochran wrote:
>
> > It sounds like 802.1-AS has a bug.
>
> I don't think this is a "bug", as it seems more like an unfortunate...
I am realizing I might have
On Thu, 1 Jun 2023 06:34:19 -0700, Richard Cochran wrote:
> It sounds like 802.1-AS has a bug.
I don't think this is a "bug", as it seems more like an unfortunate
oversight
in the original 802.1AS-2011 specification where the computation had a sign
difference. The 802.1AS-2020 specification grapp
interested in making the linuxptp
project compatible with MOTU switches based on the KSZ9567 switch IC, but
before submitting any patches I wanted to explain the motivation and see if
this is something that the project would be open to considering.
--
Dylan Robinson
Software Engineer
MOTU
17 matches
Mail list logo
