On Thu, Dec 03, 2020 at 05:52:24AM -0800, Richard Cochran wrote: > On Thu, Dec 03, 2020 at 01:22:35AM +0200, Vladimir Oltean wrote: > > > So now I will speculate a bit, and assume that the hardware behavior you > > need is for the port 1 to subtract the t1 RX timestamp from the Sync > > packet's correctionField, then the port 2 to add the t2 TX timestamp to > > the correctionField. And for the hardware to send the Sync message to > > the CPU and only to the CPU. This is the only situation that I can see, > > where the residence time would be contained into the Sync message at the > > end, and it would be forwarded by software. > > > > Let me ask you based on what criterion do you call this generic? > > Good question. > > In principle, I wouldn't mind supporting 1-step TC in ptp4l, but the > implementation would have to work with the currently available 1-step > HW. If there are different HW mechanisms, then these should be > discoverable by ptp4l via ethtool/etc in order to let the ptp4l > perform the needed adjustments. > > For example, the phyter can support 1-step E2E TC in the following way. > > While the specification calls for adding the residence time to the > correctionField, the same results may be obtained by adding the > incoming originTimestamp to the correctionField and subtracting > the ingress timestamp. Upon transmission, the egress timestamp > for the sync message will automatically be inserted into the > originTimestamp field. The processor should set: > > correctionField = correctionField + originTimestamp - > sync_ingress_timestamp > originTimestamp = 0 > > Using one-step operation, the PHY will automatically set: > > originTimestamp = sync_egress_timestamp > > Since the correctionField only supports a 16-bit seconds field, > this only works if the local PTP clock for the TC is synchronized > within 215 seconds of the master clock. Before forwarding the
Isn't this game over already? Who guarantees that the TC will be synchronized within 215 seconds of the master, considering that the spec doesn't even require the TC to synchronize to the GM in the first place, just syntonize? What if the TC doesn't even have a local persistent source of time, like my LS1021A-TSN board doesn't, and always boots in Jan 1970... This solution sounds to me like: How to synchronize two devices using a one-step IEEE 1588 transparent clock --------------------------------------------------------------------------- Use NTP. > first sync message, the transparent clock should first set the PTP > clock time and then modify the ingress time-stamp based on the > adjusted time. > > - TI Application Report AN-1838 > > This method will also work for any 1-step HW that clobbers the > Sync.originTimestamp field with the egress time stamp. I'm willing to > bet that the existing HW, > > - 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 ack for ocelot. Here's an excerpt from the documentation for one-step: Origin PTP: REW_OP[2:0] = 9. The time of day at the frame's departure time is written into the origin time stamp field in the PTP frame. > - drivers/net/phy/dp83640.c > - drivers/net/phy/mscc/mscc_ptp.c > > all do exactly this! Actually, for dpaa2, the one-step timestamping procedure just does: correctionField += t_TX - t_passed_inband where the driver populates: t_passed_inband = originTimestamp = approximate PTP time of software packet delivery and where t_TX is, of course, the precise hardware timestamp. So for this hardware, the hardware will only update the correctionField, and the driver is wired up to clobber the originTimestamp in software. In fact there is an entire class of hardware that has the concept of a t_passed_inband, the ksz9477 is one more such example. The "natural" way that this was designed to be used, for example for Sync forwarding in a one-step TC setup, is to set t_passed_inband = t1 (from the RX timestamp on the ingress port). Then, since t_TX is t2, the correctionField is updated with (t2 - t1). It's a bit odd that we would be forcing unneeded limitations to hardware that can do better. > > In order to do its job properly, the sja1105 one-step TC must be left > > alone to do its job of forwarding the packet autonomously and updating > > the residence time in the process. But not forcing the switch to send > > the Sync message to the CPU just for the CPU to send it back, because > > that would mean that the switch adds two small residence times, and the > > big one (the software latency) is completely missing from the calculation. > > +1 > > Sending Sync messages to the management CPU incurs a very large delay. > This delay is much larger than the delay between the Sync and the > generated FollowUp. > > So if your TC is implemented by ptp4l, then using 1-step doesn't > provide any benefit. So I don't actually care about one-step TC on sja1105 or in general. This discussion however seems to be leaning towards the conclusion that we should let sleeping dogs lie. Hardware one-step TCs should just do their own thing and ptp4l is just concerned with the software based ones. Ok. _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
