| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi William, I did a search on google and the following popped up: See page 10, PTP uses timestamping to overcome the problem of asymmetry. I also asked Paul and he confirmed that gPTP can handle the asymmetry. Thanks -saied From: William Lo <will@xxxxxxxxxx> Hi Saied, My point is that it is not the same in both direction. The delay of TX(L=1) + RX(L=1) != TX(L=4) + RX(L=4) != (TX(L=1) + RX(L=1) + TX(L=4) + RX(L=4) )/2 Does PTP care about this? I don’t know and that’s why I am asking.
Thanks, William From: Saied Benyamin <Saied.Benyamin@xxxxxxxxxxxx>
Hi William, I am not certain that I understood your PTP question correctly, but you do not have to worry about the asymmetry of rx/tx delays because any time you have data going from one phy to another, you go through the summation of a
transmitter and a receiver. And this is the same in both directions. Thanks -saied From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
William – In general, I think the simple approach you come to at the end (use the largest L requested, and do it symmetrically) is probably the right one. what has happened in the past (and why this is important) is that the PHYs themselves just specify the maximum delay. The network relies on this as a static parameter. If someone is engineering a network, they may know the greatest interleave value they will use, so specifying the latency vs. interleave in the standard is useful. There is no mechanism that I know of to communicate the latency, however,
one could do it through the management entity by reading the interleave setting. On question 2 – computing the latency on the fly seems to be outside our scope, and I think that 2B is a good question, and likely a problem – I am not, however, a PTP expert. -george From: William Lo <will@xxxxxxxxxx>
All, I spec some latency numbers in yesterday’s ad hoc and depending on the interleaving L=1, 2, 4 that is selected
the pause_quanta changes which is what we want since we are trading longer latency for better error correction.
The pause_quanta is used by the MAC for the pause function. This raises 2 questions for me in light of the topic raised yesterday that the MAC and PHY only has some predefined signaling
to tell each other what is going on and the PHY cannot willy-nilly affect parameters that impacts the MAC without a way to inform
the MAC. If someone knowledgeable with the MAC can chime in on the following questions it would be great.
Question 1: Let there be PHY A and PHY B and corresponding MAC A and MAC B. PHY A tells PHY B what interleaving L = 1, 2, 4 that it wants during training. So how does PHY B tell MAC B what the pause_quanta is since this value is dependent on what PHY A wants and is not known a-priori.
Question 2: The max PHY latency (which is converted into units of pause_quanta for MAC use) is defined as the sum of PHY A transmit delay + PHY A receive delay which with unequal interleaving becomes PHY A tx delay (interleaved per B’s request) + PHY A rx delay (interleaved per A’s request) Since PHY A and PHY B do not have to request identical interleaving values how is the pause quanta computed in the mixed case since
the real latency in one path is PHY A tx delay (interleaved per B’s request) + PHY B rx delay (interleaved per B’s request) and the
other path is PHY B tx delay (interleaved per A’s request) + PHY A rx delay (interleaved per A’s request) Question 2B: A related question is when we compute PTP delays, based on my limited understanding, the round trip delay is computed and we
divide by 2 to estimate the delay on the link. If we have unbalanced latency because of different interleaving, will this affect PTP?
The delay difference between L = 1 vs L = 4 (i.e. 1us) is much much larger than the propagation delay across 15m cable.
One way to solve this is that if the interleaving values requested are not identical then the larger L is the
one that has to be used by both PHYs. Thanks, William To unsubscribe from the STDS-802-3-NGAUTO list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 To unsubscribe from the STDS-802-3-NGAUTO list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 To unsubscribe from the STDS-802-3-NGAUTO list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 |