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
On Thu, 15 Jun 2023 at 06:26, Richard Cochran
wrote:
> On Wed, Jun 14, 2023 at 03:51:08PM +0200, Walfred Tedeschi via
> Linuxptp-devel wrote:
>
> > Covering for Industrial/Process automation customers that are willing to
> use
> > PMC interface to gather status of the time synchronization for the
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
