Hi Volodymyr,
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.
>
> 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
> 2. DELAY_REQ
> 3. PDELAY_RESP
>
> Any deviation (in HW) from the standard will most likely
> produce unexpected results.
>
> The general idea is that in 1-step mode HW renders time
> stamps and updates correction field, without SW's intervantion
> in the process.
>
> To make linuxptp conform to 1-step TC, a set of simple yet
> effective changes must be introduced.
>
> The following paragraph is plausible for 1-step E2E TC:
>
> SYNC, DELAY_REQ and DELAY_RESP messages need to be forwarded
> by linuxptp, without any intrusion into packets content. No
> egress time stamp will be available for these packets, since
> HW will update correction field (for SYNC & DELAY_REQ) on-the-fly.
> With this in mind, linuxptp essentially needs to skip the code
> that fetches time stamps from kernel. No other changes are needed.
>
> As for 1-step P2P TC - allowing SYNC packets to simply flow through
> without collecting egress time stamp, makes the whole idea possible.
> Thanks to the fact that peer-2-peer mechanism works identically on
> all clock types, no other changes are necessary.
>
> 1-step related prerequisites for running TC in E2E mode:
> 1. --time_stampint=onestep
>
> Two different possibilities exist for 1-step P2P TC:
> 1. --time_stamping=onestep will result in TC
> updating correction field of SYNC packets in HW.
> Peer delay mechanism will work in 2-step mode though.
>
> 2. --time_stamping=p2p1step will make TC fully compatible
> with 1-step principles of IEEE 1588 V2 standard.
>
> NOTE: --twoStepFlag=0 must be valid for both E2E & P2P.
>
> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendi...@gmail.com>
> ---
+-------------------------+
| |
| linuxptp one-step |
| P2P-TC |
| |
+-------------------------+
| | |
| port 1 | port 2 |
+------------+------------+
^ |
+------------+ | | +------------+
| | Sync | | Sync | |
| Node A |----------------+ +---------------->| Node B |
| | | |
+------------+ +------------+
Node A sends a Sync message with an originTimestamp of 1606855147.000000000,
and a correctionField of 0. The originTimestamp was taken at time
1606855147.000000000, of course.
- The link between Node A and TC port 1 has a delay of 800 ns.
- The link between Node B and TC port 2 has a delay of 700 ns.
- The NICs on port 1 and port 2 have a store-and-forward delay of 1 us
between the time they receive a packet on the MAC and when they deliver
that packet to the host.
- The time taken by the software running on the TC box to receive a packet
from the NIC, send it up the stack, to the application's socket, and
back to another socket on port 2, takes 60 us.
So the Sync message will be seen and timestamped by Node B at time
1606855147.000063500.
According to your proposal, at which steps will these latencies be
accounted for in the forwarded Sync message?
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
