I would like to join the discussion as I am also working with a 1-step TC
hardware.
The Microchip KSZ9477/9563/9567 performs forwarding of SYNC messages
in hardware by default (if not explicitly disabled, e.g. for BC). For this
type of hardware, ptp4l should not forward Sync messages at all (when
Hi Richard and thanks for your commentaries and considerations.
You are right. No hardware with support in mainstream Linux fulfils 1-step TC
directives imposed by IEEE 1588 V2 standard as of today, and that’s tragic. But
on the other hand, if we would take a wider view, HW that conforms to the
Hi Vladimir, and thank you for extra-well formulated question.
Actually, when I was drafting an answer to your question, I realized I had
missed one very important point in the patch, namely, that SYNC packets in P2P
mode should not simply be forwarded, but port’s peer delay should be added to
Welcome to the discussion Christian!
It is quite an interesting problem you’re trying to solve.
Have you already tried to implement that additional interface you mentioned?
/Volodymyr
> On 2 Dec 2020, at 10:20, Christian Eggers wrote:
>
> I would like to join the discussion as I am also workin
Hi Volodymyr,
On Wednesday, 2 December 2020, 17:39:37 CET, Volodymyr Bendiuga wrote:
> Welcome to the discussion Christian!
>
> It is quite an interesting problem you’re trying to solve.
> Have you already tried to implement that additional interface you mentioned?
no, I haven't. I am currently tr
Hi Volodymyr,
On Wed, Dec 02, 2020 at 05:31:37PM +0100, Volodymyr Bendiuga wrote:
> Hi Vladimir, and thank you for extra-well formulated question.
>
> Actually, when I was drafting an answer to your question, I realized I
> had missed one very important point in the patch, namely, that SYNC
> pack
