| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Christian, Thank you for that important clarification on the assumptions. best regards, Yong Kim |
Senior Director, CTO Office, Networking From: Christian Boiger [mailto:cb@xxxxxxxxxx]
Hi Yong, I think there is an important difference in the definition of those two latency targets, which should be pointed out: ·
The Automotive number includes the transmission time of the frame itself (at each hop) and assumes a payload of 128 bytes @ 100Mbit and 256 bytes @ GBit (payload of the high priority frames) ·
The industrial latency goal is defined in a way explicitly excluding this store and forward time Regards Christian Von: Yong (Yongbum) Kim [mailto:ybkim@xxxxxxxxxxxx]
Dear Thomas, Just answering the question by providing use case references…. The best summary, without going through prior ,
Captured in http://www.ieee802.org/1/files/public/docs2013/avb-pannell-gen2-assumptions-1113-v17.pdf Pg 9 – Automotive Summary (only two lines are copied here). -
Max Latency: 100 uSec w/5 FE hops for Control Frames
ç Also for GE, not captured in the assumptions. (the most demanding latency requirements are from Toyota contributions). -
Max end to end cable length (E2E, all cables): 30 m. Pg 10 – Industrial Summary (only two lines are copied here). -
3 uSec per hop (GE only) assuming IET/DMLT (“preemption” in 802.1bu). -
64 hops. best regards, Yong Kim |
Senior Director, CTO Office, Networking From: Hogenmueller Thomas (AE-BE/EKE) [mailto:Thomas.Hogenmueller@xxxxxxxxxxxx]
Hi Stefan and Stephane, even if I’m not working for an OEM ;-) I try to give a small hint. As you mentioned in case of a 7 hop network we would accumulated significantly latency up to 42 µs. If take a look on the requirements from IEEE802.1 TSN with
100 µs over 5 hops including Layer 2 protocols I guess this would not going to work. Compared to other Ethernet PHY I would say the latency should be below 1 µs. But I’m not expert and would like that we include the .1 one guys as well in the discussion.
Maybe Franz or Yong can give us their requirements from their Layer 2 perspective? I would not derive our requirements directly by application requirements but
more from Layer 2 Protocols. We need to ensure that these protocols can work on the new PHY. Mit freundlichen Grüßen / Best regards
Von: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
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]
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]
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]
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
|