Re: [802.3_ISAAC] Real live example of why latency maters
Hi Kirsten,
It is absolutely appropriate to look at the packet delivery time from the system point of view. In the end that is what matters to the system.
Also, as you have pointed out, PHY delay should be looked at in the overall context.
Regards
Kamal
From: Matheus Kirsten, EE-352 <Kirsten.Matheus@xxxxxx>
Date: Monday, October 7, 2024 at 4:53 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx <STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: [802.3_ISAAC] AW: [802.3_ISAAC] Real live example of why latency maters
CAUTION: This email is from an external origin!
Hi all,
To my experience, when my colleagues look at delay numbers in automotive, they are ONLY interested in the complete delay, i.e. including the packet delay. For 10BASE-T1S e.g. the delay/latency is being discussed, but not because the processing in the PHY takes any amount of time. It is because it takes 1.2336ms to receive a 1500 byte packet. I hope it is obvious, that it is (almost) irrelevant to look at the processing delay of the PHY in this case. Can we agree on that?
The 10-year old presentation cited, was looking at the requirements for 1000BASE-T1 in a backbone use case. To my understanding, also this presentation included in the 15us the packet latency and PHY delay and not just the latency it took to process the data in the PHY. The packet delay for 1Gbps is 12.336us. The defined PHY delay max per spec is 7.168us, which together means a delay of about 20us >15us. I am not aware of a single complaint in the industry that 1000BASE-T1 cannot be used in the backbone/between zones, because its delay/latency is too large.
So why are do we keep discussing this and what is so different for the 100Mbps UL for the camera use case? For 100Mbps the delay/latency is 123.36us for a the Ethernet packet size that is typically aspired to be used. As I have shown in my presentation: For the highspeed DL the processing delay is in the same range as the packet delay. However, for the low speed UL the delay is dominated by the link speed. If you add a 1Mbps I2C on top of that, that is what will dominate the delay, not the processing in the PHY (though I agree that startup is an item yet to discuss separately).
I am having a hard time to follow the logic of what this discussion is about. As a customer, I want to know, when I can use the content of the packet for further processing. For 100Mbps this is dominated by the 100Mbps interface rate. As a customer, I have no issues having even 100us in the UL for the camera control, again, as the cycle times for cameras/radars/lidars are in a different order of magnitude. I and other colleagues have brought in data that explains the rational behind this. We have looked in detail at the type of control information and data that gets transferred to the camera. What is missing?
Kind regards,
Kirsten
Von: William Lo <will@xxxxxxxxxx<mailto:will@xxxxxxxxxx>>
Gesendet: Freitag, 4. Oktober 2024 23:24
An: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Betreff: Re: [802.3_ISAAC] Real live example of why latency maters
Sent from outside the BMW organization - be CAUTIOUS, particularly with links and attachments.
Absender außerhalb der BMW Organisation - Bitte VORSICHT beim Öffnen von Links und Anhängen.
________________________________
Hi Kamal,
The presentation I referenced recommends the 15us when referring to automotive control loops
and I think it is relevant for both forward vs back channels since video data and control data forms a loop
to control the camera based on the image received. This data is especially relevant to the back channel
since the back channel is part of the control loop.
Anyway, my personal opinion is that we focus on what we are chartered to do and build consensus.
I feel a lot of the conversation going back and forth is nice to know but really outside the scope of the group.
I believe I am bringing in data that is in scope of what we need to consider.
I’m bring up a bunch of datapoints from past work in IEEE to the attention of the group who may not be aware
of past history so to help us make some decisions here. I recall the info we got in 802.3bp really informed that
group what the target needed to be and if you trace the history of the presentations in 802.3bp, the technical
decisions came quickly after the group had a latency target.
I’m hoping for the same here that this data can help us move forward in .3dm.
I respectfully disagree with your delay starting points. All BASE-T1 PHYs delays in the past fast or slow are easily under 15us.
So I don’t see why this number cannot be met in .3dm and why we shouldn’t try to do even better.
Thanks,
William
From: Kamal Dalmia <kamal@xxxxxxxxxxxxxx<mailto:kamal@xxxxxxxxxxxxxx>>
Sent: Thursday, October 3, 2024 18:54
To: William Lo <will@xxxxxxxxxx<mailto:will@xxxxxxxxxx>>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] Real live example of why latency maters
All,
I think it is premature to nail down 1 particular parameter this early on without having looked at various tradeoffs between PAM levels, echo-cancellation etc. in detail.
That being said, if we do want to start with some numbers, before we start quoting specific numbers, it should be noted that 802.3dm will be an Asymmetrical PHY. Past 802.3 automotive PHYs are symmetrical in nature. Even though several of these past PHYs were justified for Camera Applications during their CFIs, hardly any are shipping in the Camera applications. This tells me that starting with past PHYs as a base would not be a good idea.
For asymmetrical PHYs targeted at camera/sensor/display applications, one should look at FORWARD (video) direction separately from REVERSE (control) direction.
Delivery of video with low latency is as desirable as reasonable latency for control data. This means we need two separate numbers, each optimized for its specific purpose. In the past there was only one number per PHY due to symmetry.
May I suggest the following numbers as starting points –
FORWARD Direction (Video data from Camera to SOC) – Max PHY “delay” of 2 microseconds (very valuable to have video delivered to the SOC as quickly as practical)
REVERSE Direction (Control data from SOC to Camera) – Max PHY “delay” of 30 microseconds (keeping in mind that the long pole in this direction is I2C – as Scott and Steve have rightfully pointed out).
One number (such as 15 microseconds) without specifying the direction would not address the topic in a manner it should be addressed. The delay numbers should be different depending on the direction just as the data rates adopted in the project’s objective differ depending on the direction.
Please note that I am using the term “delay” as opposed to “latency”. This is because “delay” is the only parameter that is within the scope of 802.3 PHYs. William has already pointed to this parameter in his email below. Tables 149-20 and 165-18 specify “delay limits” and not latency limits. This is the time from when the data arrives at local MII to when it is delivered at the far end MII. “Latency” is a concept above physical layer and out of scope of 802.3 (even though good to look into and understand). Also, please note that the numbers in these tables are “limits”. This implies that this is the max time allowed. The actual time of delivery may be less than the max allowed.
Cheers,
Kamal
From: William Lo <will@xxxxxxxxxx<mailto:will@xxxxxxxxxx>>
Date: Thursday, October 3, 2024 at 4:28 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx> <STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_ISAAC] Real live example of why latency maters
CAUTION: This email is from an external origin!
All,
I just realized I said something that Mr. Law would ding me on.
Let me re-state what I meant to say.
I like to bring up a presentations from a long time ago presented and supported by individuals affiliated with several OEMs
that may help us bound the latency that the networking elements should target.
Thanks,
William
From: William Lo <will@xxxxxxxxxx<mailto:will@xxxxxxxxxx>>
Sent: Thursday, October 3, 2024 16:10
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] Real live example of why latency maters
All,
Can I suggest that on the topic of latency that we stop dwelling on the application level discussion
that involves software and hardware that is not part of the networking as I feel there are different use cases
and people have differing opinions. Rather let’s really focus down on the latency in only the networking elements
as that is the only thing in scope that we can influence.
I’m not saying application level discussions are not useful, but currently I don’t feel this is leading to consensus.
Anyway, I like to bring up a presentations from a long time ago presented and supported by several OEMs
that may help us bound the latency that the networking elements should target.
https://grouper.ieee.org/groups/802/3/bp/public/may14/Krieger_3bp_01_0514.pdf
It recommends bounding the point to point latency to be less than 15 us.
All the automotive PHYs from 10Mb/s to 25Gb/s have been within this limit ever since.
For reference on the automotive PHYs
10BASE_T1L (Clause 146.10) – 3.2us + 6.4us = 9.6us.
10BASE-T1S (Clause 147.11) – Worst case 440ns + 4us = 4.440us.
100BASE-T1 (Clause 96.10) – 360ns TX + 960ns RX = 1.32us.
1000BASE-T1 (Clause 97.10) – 7168ns.
Multi-gig depending on interleaving.
[cid:image010.png@01DB18BD.06CDAE70]
[cid:image011.png@01DB18BD.06CDAE70]
In all cases things are well under 15us.
So I think this 15us upper limit is a reasonable limit we should use and strive to come in comfortably below this.
Thanks,
William
From: Mehmet Tazebay <00002b0d1a6e9d74-dmarc-request@xxxxxxxxxxxxxxxxx<mailto:00002b0d1a6e9d74-dmarc-request@xxxxxxxxxxxxxxxxx>>
Sent: Thursday, October 3, 2024 13:24
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] Real live example of why latency maters
Hi Ragnar,
There is no disagreement that the latency matters. We are in agreement there.
However, the disconnect still stands for
1. The 8 seconds application latency failure in the news that you’ve quoted (where the OEM failed 2 seconds requirement hence causing the recall)
2. The real applications have a built-in ~50 milliseconds latency (as presented in Hamburg and even before)
3. While we are dwelling on the impact of the PHY latency (in the order of tens of microseconds!) on #1 and #2 which are in seconds.
The key takeaway for me, yes, the latency matters but the impact of the PHY latency is really minuscule compared to other big ticket items as described before by the others in the group.
Would you not agree?
Mehmet
From: Ragnar Jonsson <rjonsson@xxxxxxxxxxx<mailto:rjonsson@xxxxxxxxxxx>>
Sent: Thursday, October 3, 2024 11:14 AM
To: Mehmet Tazebay <mehmet.tazebay@xxxxxxxxxxxx<mailto:mehmet.tazebay@xxxxxxxxxxxx>>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: RE: [EXTERNAL] Re: [802.3_ISAAC] Real live example of why latency maters
Hi Mehmet,
The direct relationship with our discussion is to slide 8 of TJ’s presentation in Hamburg: https://www.ieee802.org/3/dm/public/0924/Houck_Fuller_3dm_03_0917.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__www.ieee802.org_3_dm_public_0924_Houck-5FFuller-5F3dm-5F03-5F0917.pdf-26source-3Dgmail-2Dimap-26ust-3D1728573952000000-26usg-3DAOvVaw0oPAOigIEgH1pTwe-5FN-2DYKb&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=hiHgBSUj2X0k3TORVxe0NCZAlJs6SEDHhwLDz5m9MbY&m=liiN1Ttu89AIRFTzhvy4uu5eLrWctw5e3e_3GHxhrDoq0M1WIKGEyWp03rhfjuSc&s=nvZ-m1lu2gEfvg3FN01LzBRAnDCaQvIgPqvgjLdZr-c&e=>
This slide talks explicitly about the 2 second requirement and how it relates to link latency.
The takeaway is that latency matters.
Ragnar
On Oct 3, 2024, at 1:50 PM, Mehmet Tazebay <000007de4eafb912-dmarc-request@xxxxxxxxxxxxxxxxx<mailto:000007de4eafb912-dmarc-request@xxxxxxxxxxxxxxxxx>> wrote:
Ragnar,
Thank you for bringing this piece of news to our attention but I do not follow how 8 seconds violation relates to the topic of microseconds PHY latency discussion here. This particular OEM is violating by seconds and that is a very big issue but we are discussing microseconds for the PHY here!
All,
Just to put everything in context, even though we are trying to be conscious of latency impact -as we should be-, here we are discussing PHY latency, for example, between ~5 microseconds versus ~25 microseconds. On the other hand, the real application has about 50 milliseconds latency according to the data that has been shown by Gollob, Matheus, and others. From what I understand this is coming from a real application and that is a lot more than the PHY latency!
So, what does this all mean? Yes, the latency is important but we should not narrow down the solution space based on microsecond latency difference constraint. Instead, we should keep looking at the big picture and find the best possible solution for 802.3dm.
Regards,
Mehmet
On Oct 3, 2024, at 11:25 AM, Ragnar Jonsson <rjonsson@xxxxxxxxxxx<mailto:rjonsson@xxxxxxxxxxx>> wrote:
All,
We have been having considerable discussion about latency, and how important it is. In case anyone was only thinking of this as an academic problem, I urge you to read about the recall of 27,000 Cybertruks because of latency issue with the rearview camera. According to https://www.cnn.com/2024/10/03/business/tesla-cybertruck-recall-october-2024/index.html<https://www.google.com/url?q=https://www.cnn.com/2024/10/03/business/tesla-cybertruck-recall-october-2024/index.html&source=gmail-imap&ust=1728573952000000&usg=AOvVaw32-Us42D-ZmcQOOVbrXpHc>:
“The rearview display might appear blank for up to 8 seconds when the Cybertruck is put in reverse, according to a filing<https://www.google.com/url?q=https://static.nhtsa.gov/odi/rcl/2024/RCLRPT-24V718-2751.PDF&source=gmail-imap&ust=1728573952000000&usg=AOvVaw1RMU_Ofj2i6f082HWjXlrW> from the National Highway Traffic Safety Administration (NHTSA). That’s well beyond the 2 seconds required by US federal safety rules.”
I think that this is a very strong argument in favor of what TJ has been preaching on latency. This relates directly to slide 8 of TJ’s presentation in Hamburg: https://www.ieee802.org/3/dm/public/0924/Houck_Fuller_3dm_03_0917.pdf<https://www.google.com/url?q=https://www.ieee802.org/3/dm/public/0924/Houck_Fuller_3dm_03_0917.pdf&source=gmail-imap&ust=1728573952000000&usg=AOvVaw0oPAOigIEgH1pTwe_N-YKb>
I also like to remind everyone of Ariel’s comment in Hamburg, where he pointed out that the 2 seconds are for the whole system, so the camera needs to be up and running in much shorter time.
The bottom line is this: Latency matters.
Ragnar
________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
________________________________
This email has been scanned for spam and viruses by Proofpoint Essentials. Click here<https://us2.proofpointessentials.com/app/report_spam.php?mod_id=11&mod_option=logitem&report=1&type=easyspam&k=k1&payload=53616c7465645f5f0849af852276bcb6a45af3c6c2eb390167ea44b14a72e31442ee195a228e9f8fdf1448f970a6b815be91d5ce810ceaa65d7795730ccc551fe41881cad2d2fbcaadad20c0a14a458959488a51431a9505814b5fa73b9b7e2fb4e8ae1cbdc847e8e80d35b32722b76148f015d8baf9a903210bfac6895a5e708c41799282e63b138c0f3b191bdbecb5cc7bd5d44841ccb7137ff74af86c1b8f> to report this email as spam.
________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1