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 named standard does exist, and has been around for quite some time, which makes me think that there must be individuals/companies out there, using such HW.
We use Marvell’s Alaska 1548P phyter, fully capable of 1-step operation according to already named standard. It is not yet in mainstream linux though. What we’ve seen so far in Linux, concerning 1-step PTP, are basically drivers for HW that only to a limited extend implement PTP features. Which is, I will repeat myself, tragic. For HW that does a plain write operation to the correction field, this patch would do little; not because the patch itself is poorly designed, but because given HW does not do the job correctly, since correction field is there so that a total sum of residence time from x number of devices should be accumulated there. It is not an intention to disqualify such HW, but the opposite: for linuxptp to support it, a special case would have to be handled. This is not the case with generic solution. Considering the situation we find ourselves in, I do believe that generic solution for 1-step TC would motivate HW/SW developers towards better designs and conformance to the standard. It would also attract new users of linuxptp who might in turn make their contribution to yet better ‘linuxptp-next’, so to speak. Another great thing with generic solution, is that it is simple and does not require any ‘hack’ in SW, and also, it does not interfere with any other existing feature or mode of operation. It is simply there, as a pleasant bonus, for those who have relevant HW. No new APIs, extensions or parameters are needed, since everything already is in place, and that is inviting. All HW that can not use generic solution, may simply skip it, whereas those that can use it - will use it. This seems to me like a win-win situation where no party is hurt. Actually, generic solution does not require any HW in order to be implemented, since its main guidelines are written in the standard, and that’s one of the motivations. What are your thoughts Richard? /Volodymyr > On 1 Dec 2020, at 20:23, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Tue, Dec 01, 2020 at 05:14:38PM +0100, Volodymyr Bendiuga wrote: >> From: Volodymyr Bendiuga <volodymyr.bendi...@westermo.se> >> >> This tiny patch provides generic solution for 1-step >> E2E & P2P Transparent Clocks. > > The small code change (or something like it) would be fine, but there > is a larger issue that you need to address, first. > >> Before revealing any further details, I want to state >> in plain words that changes brought about in this patch >> will only work for HW that is compliant with IEEE 1588 V2 >> standard, with regard to Transparent Clock and 1-step >> operation. That is to say, HW that is capable of updating >> correction field on-the-fly, for the following packets: >> 1. SYNC > > So what HW actually does this? I just looked... > > Only one driver implements HWTSTAMP_TX_ONESTEP_P2P, namely > drivers/ptp/ptp_ines.c. It have this HW for testing. That one > updates the originTimestamp of Sync messages, IIRC. > > These are the drivers that implement HWTSTAMP_TX_ONESTEP_SYNC. > > - drivers/net/ethernet/cadence/macb_main.c > - drivers/net/ethernet/freescale/dpaa2/ > - drivers/net/ethernet/microchip/lan743x_ptp.c > - drivers/net/ethernet/mscc/ocelot.c > - drivers/net/phy/dp83640.c > - drivers/net/phy/mscc/mscc_ptp.c > > Of these, I only have the dp83640 available for testing. That one > updates the originTimestamp. > > What do the others do? > > It appears that ocelot *can* update the correction field, > > case HWTSTAMP_TX_ONESTEP_SYNC > /* IFH_REW_OP_ONE_STEP_PTP updates the correctional field, we > * need to update the origin time. > */ > ocelot_port->ptp_cmd = IFH_REW_OP_ORIGIN_PTP; > > but does it clobber the correction field or accumulate? It is an > important difference! > > So what HW will support this new TC 1-step Sync? None at all, AFAICT. > > If you want to support 1-step TC, then you are going to have to do > some background work: > > - Expand the kernel driver interface to make it clear that a given HW > performs correctionField accumulation. > > - Advertise that via ethtool get_ts_info. > > - Get a driver merged that implements this. > > - Expand ptp4l's time_stamping option to make use of the new feature. > > Thanks, > Richard > > > >
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
