Re: [Linuxptp-users] Confused about one-step P2P OC versus EEE1588v2 spec

[Janusz U. <j.u...@el...>]

Hi,

Any news about the topic?
I got only "Your message to the list 'linuxptp-users' has been forwarded 
to the
moderator(s)" as feedback.

best regards,
Janusz



W dniu 20.06.2023 o 16:50, Janusz Użycki pisze:
> Hi.
>
>
> In Linux kernel HWTSTAMP_TX_ONESTEP_P2P is introduced as feature 
> superset of HWTSTAMP_TX_ONESTEP_SYNC for peer delay. However only few 
> device drivers and its hardware support full P2P one-step timestamping.
>
> It is not clear if one-step SYNC and two-step Pdelay method in P2P can 
> be mixed together (by single OC/BC master) when 
> HWTSTAMP_TX_ONESTEP_SYNC is supported only:
>
> - According to IEEE1588-2008 specification (11.4.3) peer delay 
> responder one-step clock "SHALL" (key word) update Pdelay_resp on the 
> fly so it seems they can't be mixed.
>
> - Moreover "one-step clock" term suggests it is clock property, not 
> port timestamping ability. On the other hand it seems artifical 
> requirement.
>
> 1. Can you clarify for one-step P2P what is met in the field (eg. PTP 
> Plugfest) ?
>
> 2. And what is formal IEEE1588 requirement/statement ?
>
> 3. Is such P2P mix supported/handled properly by TC and OC/BC slaves? 
> It looks supported (both OC slave and master) by linuxptp 4.0 and 3.1 
> (port.c::process_pdelay_req()).
>
> 4. The latest gPTP and power profile have recommendation for one-step. 
> Do they allow/mean one-step SYNC only or full P2P with Pdelay ?
>
>
> best regards
> Janusz
>
>
>
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users