Hi Ragnar,
Thanks for confirming that we are still on the same page regarding latency. I completely agree with you that we should focus our upcoming discussions on objective evaluations
of the requirements of our target market and avoid continuing to spend energy on distinctions that are not showstoppers.
Thanks, and best regards,
Steve
From: Ragnar Jonsson <rjonsson@xxxxxxxxxxx>
Sent: Thursday, October 3, 2024 5:24 PM
To: Steve Gorshe - C33336 <Steve.Gorshe@xxxxxxxxxxxxx>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Real live example of why latency maters
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Hi Steve,
Regarding your statement
“Latency does still not represent a crucial decision item in respect to distinguishing between the different duplexing schemes.”,
I agree with this. I have said many times and I say this again, that both ACT and TDD can meet TJ’s latency requirements.
I think that it would be very unfortunate if the group gets so hung up on indirect discussion about ACT vs ASA-MLE that we can not discuss important requirements in an objective
way. I have already provided my initial comparison of ACT and ASA-MLE and I never brought up latency in that comparison, because I think it is mostly immaterial for this comparison (see
https://www.ieee802.org/3/dm/public/0924/jonsson_razavi_3dm_01_09_15_24.pdf). ASA-MLE has too high latency for 10Gbps, but this is easily fixed and should not be a showstopper.
The important thing is that we look at all the requirements, including latency, and have an honest discussion about what is needed in the market.
All I wanted to communicate with my initial email on this subject is that
latency is important.
Ragnar
Hi All, I think that Mehmet’s initial response captures it well that the latency difference between the PHYs technologies under consideration (in the range of ≈20µs)
has no meaningful difference here. The houck_fuller slide 8 certainly illustrates
Hi All,
I think that Mehmet’s initial response captures it well that the latency difference between the PHYs technologies under consideration (in the range of ≈20µs) has no meaningful
difference here. The houck_fuller slide 8 certainly illustrates that under certain assumptions, non-optimum implementation choices could impact latency. However, both of Kirsten’s contributions and the gorshe contribution dispute some of those assumptions
(e.g., the number of camera update commands that need to be sent in a given timeframe). Even if we leave assumptions aside, nothing in that slide 8 demonstrates that any of the PHY technologies under consideration would lead to exceeding the system level
2 second target. The most comprehensive analysis of system level latency requirements came from the Gollob presentation. His first conclusion was that “Computing dominates whole video processing latency by several orders of magnitude over the communication
latency.” At one point during the meeting, we appeared to have agreement (which I thought I remember being supported by Ragnar) with Kirsten’s conclusion in her 01 contribution that “Latency does still not represent a crucial decision item in respect to
distinguishing between the different duplexing schemes.” Consequently, while the problems of the cybertruck (or which there are several) are interesting, it’s not obvious to me that this email thread is helping us to move our P802.3dm project forward.
Best regards,
Steve
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Mehmet,
The PHY latency of microseconds creates a huge difference in the
system performance/latency.
In the use-case that TJ described in
slide 8 in
https://www.ieee802.org/3/dm/public/0924/Houck_Fuller_3dm_03_0917.pdf (which is applicable to the live example that Ragnar shared below), there is a very big difference between the “12us” proposed by TJ, compare to the “100us” proposed in
https://www.ieee802.org/3/dm/public/0724/matheus_dm_02b_latency_07152024.pdf (slide 9): This is the difference between 60ms (based on 12us) to 500ms (based on 100us), with the example of 5000 commands initialization process.
This is almost 0.5 second that you eat from the “2 seconds” target of NHTSA. This is 25% of the budget. So Yes, few tens of microseconds difference in PHY latency makes a huge difference in overall
system performance and the ability to meet the NHTSA requirements.
Thanks,
Amir
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
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.
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!
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.
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:
“The rearview display might appear blank for up to 8 seconds when the Cybertruck is put in reverse, according to a filing 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
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
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
|