Re: [802.3_ISAAC] Real live example of why latency maters

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

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>
Sent: Thursday, October 3, 2024 16:10
To: 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.

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>
Sent: Thursday, October 3, 2024 13:24
To: 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>
Sent: Thursday, October 3, 2024 11:14 AM
To: Mehmet Tazebay <mehmet.tazebay@xxxxxxxxxxxx>; 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

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> 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> 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:

“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