Hi Scott,
All I wanted to communicate with my initial email on this subject is that
latency is important.
If you have information that contradict TJ’s analysis, then I would encourage you to bring in concreate examples about current implementations that dispute his analysis. TJ’s analysis is not saying that it
is not possible to do better, but rather analyzing what is common practice today.
Regarding your statement “so other than reminding us of the 2 second limit from backup event to image display it doesn’t seem to relate
to 802.3dm”, I agree with you. However, the 2 second limit is clearly very important and very relevant to 802.3dm. This is what I wanted to communicate by sharing this link. This is “Real live example of why latency maters”
(hence the subject matter for my email).
Ragnar
From: Scott.Muma@xxxxxxxxxxxxx <Scott.Muma@xxxxxxxxxxxxx>
Sent: Thursday, October 3, 2024 4:45 PM
To: Ragnar Jonsson <rjonsson@xxxxxxxxxxx>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Real live example of why latency maters
Hi Ragnar, I suspect that it’s just very confusing to talk about PHY latency and system level event-to-result latency as both being “latency”. I agree that PHY
latency matters up to a point, but this recall doesn’t provide us with any convincing
Hi Ragnar,
I suspect that it’s just very confusing to talk about PHY latency and system level event-to-result latency as both being “latency”.
I agree that PHY latency matters up to a point, but this recall doesn’t provide us with any convincing information about PHY latency. It seems very unlikely that the recall
was addressed by reducing the PHY latency, so other than reminding us of the 2 second limit from backup event to image display it doesn’t seem to relate to 802.3dm.
From TJ’s presentation I was able to understand that byte-mode I2C transfers that wait for the far-end to send an ACK for each byte are not appropriate in a multi-hop network
and will break the system performance as soon as they are extended beyond the most trivial point-to-point case. The link initialization case of needing to send 5000 register accesses can be addressed in multiple different ways though to take advantage of
the network bandwidth without suffering the full end-to-end latency on every byte transferred.
Slide 8 shows there are 5000 commands at 1Mbps taking 140ms, so we can infer there are approximately 5000 bytes of data, and 10000 bytes of address transferred. If the 802.3dm
upstream link bandwidth is 100Mbps and even if each command (address+data) goes into its own 64-Byte packet, it should take less than 35ms of link time to transfer all of these packets. Or put another way, a single I2C command will take about 28us, but it
will only take 6.7us to send this packet on the upstream link on average. The link will mostly be waiting for the I2C. TJ’s Slide 8 completely ignores any concurrency in this process though which does not seem realistic… the I2C transactions from the SoC
to the switch and the commands at the sensor PHY to the imager will also be mostly concurrent with packets in flight. So rather than a total of 830ms a more realistic number here would seem to be link-up time + I2C time + PHY latency = 50ms+140ms+~(PHY latency).
So with PHY latencies being discussed of <100us the impact of PHY latency on system initialization will be negligible as long as the system doesn’t insist on receiving a far-end response/ACK back for every I2C command before proceeding with the next command.
Another way to say this would be that in an always-transmitting upstream link it is mostly waiting for the next I2C command. For a TDD link it may buffer a few commands while
waiting for a transmit opportunity, and then send a burst of 3-4 command frames at which point it is caught up and waiting on I2C again. In either case, if the higher level protocol allows, multiple I2C commands could be combined into one frame to reduce
overhead and conserve bandwidth and reduce contention. By choosing an appropriate I2C handling method the system initialization time can be determined by the I2C interface bandwidth, and be independent of the PHY latency.
In summary, I agree that any of the PHY approaches discussed so far would let 802.3dm achieve acceptable PHY latency and quite good system performance/initialization time, even
meeting the 300ms target mentioned. The 1 second impact TJ calculated on slide 8 seems to be unnecessarily pessimistic.
Best Regards,
Scott
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Hi Mehmet,
It is good to see that we agree that latency maters. That was all I wanted to communicate with my original email on this thread.
We may still not be completely aligned on what the latency targets should be, or how important latency is. The short latencies will accumulate and will significantly impact the startup time budget, like Amir
explains in this thread and TJ explained on SLIDE 8 of his presentation
https://www.ieee802.org/3/dm/public/0924/Houck_Fuller_3dm_03_0917.pdf
Looking more closely at the email thread below, I realize that you may have interpreted my comments to imply that latency is the only thing that matters, which is not at all what I meant. You say below:
“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.”
I agree with you 100% on this. In fact, I keep pointing out that both ACT and TDD can meet the latency requirements suggested by TJ. If you look at my comparison of ACT and ASA-MLE you will see that I do not
mention latency at all in my comparison (see
https://www.ieee802.org/3/dm/public/0924/jonsson_razavi_3dm_01_09_15_24.pdf). This is because 2.5Gbps and 5Gbps ASA-MLE can meet the latency suggested by TJ. The 10Gbps ASA-MLE has too high latency, but this can easily be fixed.
Ragnar
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