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
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
- drivers/net/phy/dp83640.c
- drivers/net/phy/mscc/mscc_ptp.c
all do exactly this!
My expectation is that any new ptp4l mode support the existing 1-step HW.
But the real question is whether people want/need this at all... more below...
> fact, the host port is not special at all when operating in the one-step
> TC mode. The switch doesn't record precise timestamps, it just increments
> the correctionField with its residence time (i.e. it takes an internal
> timestamp at the ingress of a PTP event message, another internal timestamp
> at its egress, and rewrites the correctionField adding this delta to it).
Right. This is how I would expect 1-step TC HW to work!
> 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.
> To me, a generic solution is one that would work when ports 1 and 2
> belong to the same hardware switch, but also when the boundary_clock_jbod
> option is turned to 1 (and of course, with the PHCs on port 1 and 2
> synchronized appropriately).
+1
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
