Hi Vladimir, and thank you for extra-well formulated question.
Actually, when I was drafting an answer to your question, I realized I had
missed one very important point in the patch, namely, that SYNC packets in P2P
mode should not simply be forwarded, but port’s peer delay should be added to
the correction field prior to forwarding. I apologize for the confusion I may
have unintentionally created.
This is what I have missed in the patch in tc_fwd_event() function code-wise:
if ((q->timestamping >= TS_ONESTEP) && (msg_type(msg) == SYNC))
{
corr = tmv_to_TimeInterval(q->peer_delay);
corr += q->asymmetry;
msg->header.correction += host2net64(corr);
}
cnt = transport_send(p->trp, &p->fda, TRANS_DEFER_EVENT, msg);
I will update the patch and send it anew.
Taking into account your diagram, P2P-TC calculates uplink delay between its
port 1 and Node A, by means of PD_REQ/PD_RESP messages. This delay is then
stored in linuxptp (q->peer_delay). In your case we suppose it is 800 ns.
Downstream link delay (port 2 -> Node B) is disregarded by P2P TC, since Node B
will use it on its side (over there it will be called uplink delay), upon
reception of SYNC packet.
When SYNC packet arrives to TC, we add uplink ports peer delay to
correction field and forward it. TC’s port 2 will calculate residence time and
add it to correction field. Here, the travel path of SYNC packet, from its
ingress at t1, up to linuxptp and down back to driver, will be resolved in port
2 upon egress when t2 is taken ((t2 - t1) -> add to correction field.
Upon reception of the SYNC packet, Node B will have everything it needs
to calculate the offset: origin time and correction value from SYNC packet, and
its own uplink delay (700 ns). Nothing really special going on here, just
regular workflow.
As for store-and-forward: unless you can switch it off, like placing
your hw in cut-through mode, you may have to compensate for it in link
asymmetry, but that depends on you HW design.
I guess my explanation is totally redundant, since I’ve revealed the missing
code … . Sorry once again.
/Volodymyr
> On 1 Dec 2020, at 22:07, Vladimir Oltean <olte...@gmail.com> wrote:
>
> 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
