| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Tom,
Just a word about FEC in EPON. In EFM we used a frame based FEC. In hind sight this was not a good choice as it resulted in excessive buffering required at the OLT. The stream based FEC approach in 10G-EPON was much simpler to implement.
I don’t recall any presentations on “test points up and down the stack”, but I might be mistaken.
Best Regards,
Duane
FutureWei Technologies Inc.
Director, Access R&D
919 418 4741
Raleigh, NC
From: Tom Brown [mailto:tkbrown@xxxxxxxxxxx]
Sent: Wednesday, January 29, 2014 10:39 AM
To: STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_RTPGE] Latency requirement for FEC decision
Geoff
Excellent response, I think we are on the same page. I wonder if we can borrow from other standards in .3 that have gone through this with a buffered\FEC in the PHY. A couple that come to mind are 802.3bj and EPON. If they had a model with the test points up and down the stack we can see if we can reuse or translate to the automotive\industrial space to get the delay conversation to be apples to apples.
Do you have any recommendations of good starting points?
Regards,
Tom
From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: Tuesday, January 28, 2014 6:53 PM
To: Tom Brown
Cc: Geoff Thompson; STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_RTPGE] Latency requirement for FEC decision
Tom-
In order to come up with the numbers we need we are going to have to be able to crisply define test points to use for timing at several points up and down the stack.
That isn't too bad a problem on single threaded MACs siting on top of a legacy unbuffered MAC.
Buffered PHYs and FEC complicate the equation considerably.
Thus all of the conversations about delay will be apples and oranges until we agree upon a precise vocabulary for this.
Best regards,
Geoff Thompson
On Jan 28, 2014, at 4:07 PM, Tom Brown wrote:
Hi Stefan,
Thank you for starting this thread. It has made me realize that the answer to the latency question has to answered at the top layer of the network, taking network topologies and MTUs into account. All known latencies must accounted very well because of the multiplicative “N” hop factor. Hence, small latencies at the PHY become quite large. We are still evaluating the PHY and FEC solution with a big variable being the interleaving factor of the FEC solution. This factor cannot be taken lightly because of the multiplicative factor as you have elaborated on. Let us make some more progress in the PHY group and then we will identify the latencies and roll this analysis back up to the top to verify that all applications are satisfied.
I also understand your concern on the power consumption issues and we will track that as we explore the solutions.
Regards,
Tom
From: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Sent: Monday, January 27, 2014 10:50 AM
To: STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxx
Subject: [802.3_RTPGE] AW: Latency requirement for FEC decission
Hello Stephane,
I added the IEEE reflector again, as I think it’s important to have the same understanding of the requirements between OEMs and PHY vendors and I am also not sure, if we have really detailed this…
So, from my understanding the 5...6µs we discuss would mean the overall link latency of the PHY- and DATALink-layer for an single link of an RTPGE* network (that also means these values would be added up on multiple links). For an 7-hop network this leads to maybe to 7*5…6µs = 35…42µs, however above the data link at both end-points (not in the individual hops) the message has to go through all the higher ISO/OSI layers which also adds significant delay, so this is not the final end-to-end latency at application level.
From my point of view the most critical application is some control loop between different ECU’s, e.g. for autonomous driving or other driver assistance applications and here we need to maintain low latencies - not only on the PHY- and DATALINK-layers, but also on the higher layers (to avoid e.g. an oscillation of the control loop or to slow reaction).
During discussions in Indian Wells I understood that the FEC per frame (is this meant to be an Ethernet frame (MTU=1500Byte) or are there any specific “FEC frames” inside PHY layer defined??) would led to ~1,5µs plus minor overhead to the rest of the processing so that in sum we are around 2µs, maybe 3µs. If the FEC is extended to 2 frames this would be in the range of 2*1,5µs = 3µs plus some overhead, maybe 4…5µs. The delay of the FEC itself would be constant and independent of any disturbance (as long as the transmission does not drop the complete frame to too much errors. This is because we would have to wait until the complete data (e.g. 2 frames) for error correction are received.
The question in Indian Wells was, if this amount of delay for an individual link is acceptable or not and based on the above assumptions I didn’t saw any reason why we need to avoid a 2-frame FEC. However I didn’t know the discussion about DMLT/IET and I don’t know the reason why 1µs was not an acceptable latency in this case…
So if there are from OEM’s point of view any reasons (I maybe missed) why this latency would cause a problem or if there are any applications which need dedicated latency please share.
Regards, Stefan
PS: As I am writing to the reflector: another point which is important for OEMs is for sure the power consumption. So if we could see differences between different modulations, FECs, etc. on the basis of an relative power consumption this also would help us to come to a consensus. This however should always be in relation to the overall port power, e.g if 1-frame FEC versus 2-frame FEC is twice the power for the FECs, but does not have significant influence on the over all PHY power consumption (e.g 1-frame FEC = 100% vs. 2-frame FEC = 101%) this is not a strong criteria to use for an decision.
* from now on most probably called “1000Base-T1”.
Von: KORZIN Stephane [mailto:stephane.korzin@xxxxxxxxxxx]
Gesendet: Montag, 27. Januar 2014 09:40
An: Mehmet Tazebay; Buntz, Stefan (059)
Betreff: RE: Latency requirement for FEC decission
Mehmet, Stefan,
Could you please explain what’s included in those 5 to 6 µs?
From Vitesse presentation at Indian Wells, I understood that FEC could add some time to the frame transmission. But a 1500-byte frame duration is ~1.5 µs. So 5 to 6 µs seems quite long to me.
Are those µs time spent in the receiver PHY to correct errors?
How does it propagate through switches, let’s say with 5 to 7 hops? Do we have “chances” that the cause for the error burst compromises not only 1 link but multiple links along the path from the source node to the destination node?
Is this latency constant, whatever the number of errors?
I remember presentations on Internet backbone, where they requested high-priority frames reception to force a switch to stop its transmission of a low-priority frame and start retransmission of the high-priority frame immediately. It seemed like waiting for 1µs was not acceptable. So how about 5 to 6 µs? I don’t know how these requests were finally considered. Do you know?
Best regards,
Stephane.
De : Mehmet Tazebay [mailto:mtazebay@xxxxxxxxxxxx]
Envoyé : samedi 25 janvier 2014 05:40
À : STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxG
Objet : Re: [802.3_RTPGE] Latency requirement for FEC decission
Thank you, Stefan. This is very useful. We look forward to hear other OEM inputs as well.
Best regards,
Mehmet
From: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Sent: Friday, January 24, 2014 10:18 AM
To: STDS-802-3-RTPGE@xxxxxxxxxxxxxxxxx
Subject: [802.3_RTPGE] Latency requirement for FEC decission
Dear all,
as discussed during this week’s ad hoc, I’ve internally asked for feedback regarding the latency requirement for the error correction decision.
As a first feedback from Daimler side, I can say that a latency of 5µs...6µs seems not to be an issue for our systems. I guess this opens the possibilities
for different FEC solutions.
Hopefully other car manufacturers can add their opinion by replying to this e-mail to get a wider view of the requirements
Regards,
Stefan
If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.