Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi George. I agree with you that I don’t think one static latency number to cover all interleaving options will be useful as there is no way
to bound the PHY latency between vendors if the lower latency options are chosen. And the whole point of picking a
lower interleave number is to have lower worst case latency independent of which vendor’s device is used.
Also if there is only 1 worst case number then everyone will pick the highest interleaving option as it has
better noise protection. So that brings us back to how do we solve question #1 then.
Do we define a way to communicate pause_quanta between PHY and MAC in the standard?
It may be worthwhile tackling this now as a service to humanity since FEC is going to be used more and more at high speeds in the future for other PHYs and there will always be tradeoff between latency and protection.
Any other people have ideas? Thanks, William 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 |