| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Scott, Thanks for the quick follow up. Sorry for my delayed response I was traveling this weekend. Slide 9 is a crucial part of our discussion. Do you think the 100usec latencies accurately reflect the use case in today's applications? This slide seems to be overlooked, but in my opinion, it's the most
critical one. I used to deal with this issue daily, and my slides only touch on the PHY latency to illustrate its severity. If we factor in the I2C latencies, as I did in the previous slide, the situation could be even worse. See responses below in
BLUE I'm not talking about bulk mode in this particular case. Bulk mode is independent and could work for anything, and I agree it's in the future. I'm talking about early local ACK of each I2C command by the switch and support for a few concurrent in-flight commands (one I2C command per Ethernet frame does not require bulk mode). I understood your slide 8 example is carrying a command per packet and then freezing the I2C at the SoC until that command is carried to the sensor, played out and an ACK of the command returned (your example shows 5000 I2C Acknowledges). If the system was only sending one byte (rather than one command) per packet it would be even worse of course.
This is the statement I was referring to for bulk – how else would you get 35msecs?
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. I show in my slides
each command takes 100usec. This is the number proposed in the previous presentation. If you’re not referring to bulk transfer, how can this lower latency be achieved?
This is how I got the number 100usec/packet x 5000 commands – 1 command = 28bits (didn’t include stop bits) If 5000 commands only take 35msecs, you’re saying this is taking
7usec per command/packet if this is not using bulk mode. This is not possible today, as William and Max pointed out. Since the limit is 2s, but the target is really <300ms, in the slide 8 example even assuming a network latency of 0 (saving 550ms) the initialization time is >400ms, so it doesn't seem like a good starting point to achieve the <300ms target. By making use of the early local ACK it seems possible to reduce the starting point to <300ms and it will not increase significantly with a realistic (non-zero) PHY latency, making the <300ms target achievable even over a more complex network.
I am not following I am assuming there are Auto-ACKs are taking place as I show in the breakdown below and what I mean with a “command”.
Start: 1 bit
Add: 8 bit + 1 ACK
Add: 8 bit + 1ACK
Data: 8 bit + 1ACK
Otherwise, each byte would get sent out not a “command” due to the needed ACKs. The ACKs being returned are the actual ACK/NACKs from the Imager.
I did not intend to suggest that the example is incorrectly capturing/calculating some of today's realistic implementations (and showing the impact of future PHY/network latency on this approach), but I would suggest that a change in approach is already necessary outside of the PHY to achieve the <300ms target, even in a point-to-point system. Assuming implementations would not take advantage of available standards and technology to meet these system performance targets in the coming years seems unnecessarily pessimistic. That is why I said the 1 second calculation (the result, not the calculation method) is unnecessarily pessimistic, but I should have worded that differently.
Thanks for the clarification, and no worries. Keep in mind that <300ms is a nice to-have function. In my past life, 500msec was what they wanted to have in place. Tier 1s will
give the rest of the system 1.5 seconds to do proper loading and configuration. When 15usecs are used, this is a significant improvement, reducing the time to 75msecs compared to 500msecs, saving 425msecs. The forward channel will also have significant savings.
Let’s say 4usec is used. This would be an additional 30msecs savings. With a total of 455msecs of savings,
our system's performance is significantly improved. As William and Max have shown, these numbers are not just theoretical but can easily be achieved in practice.
Meaning the link is now down to
509msecs, only 9 msecs over – if 12usecs (US) and 3us (DS) are used this saves another 15msecs+5msecs =
489msecs to complete the whole link while still using I2C, which SERDES and processor support today
Best Regards , TJ From: Scott Muma <00003414ca8b162c-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi All, Apologies for replying to multiple emails at once, but appreciate the good discussion. Hi Kamal, That is a good topic, which deserves its own thread. Hi
TJ, I'm not talking about bulk mode in this particular case. Bulk mode is independent Hi All,
Apologies for replying to multiple emails at once, but appreciate the good discussion.
Hi Kamal,
That is a good topic, which deserves its own thread.
Hi TJ,
I'm not talking about bulk mode in this particular case. Bulk mode is independent and could work for anything, and I agree it's in the future. I'm talking about early local ACK of each I2C command by the switch and support for a few concurrent in-flight commands (one I2C command per Ethernet frame does not require bulk mode). I understood your slide 8 example is carrying a command per packet and then freezing the I2C at the SoC until that command is carried to the sensor, played out and an ACK of the command returned (your example shows 5000 I2C Acknowledges). If the system was only sending one byte (rather than one command) per packet it would be even worse of course.
Since the limit is 2s, but the target is really <300ms, in the slide 8 example even assuming a network latency of 0 (saving 550ms) the initialization time is >400ms, so it doesn't seem like a good starting point to achieve the <300ms target. By making use of the early local ACK it seems possible to reduce the starting point to <300ms and it will not increase significantly with a realistic (non-zero) PHY latency, making the <300ms target achievable even over a more complex network.
I did not intend to suggest that the example is incorrectly capturing/calculating some of today's realistic implementations (and showing the impact of future PHY/network latency on this approach), but I would suggest that a change in approach is already necessary outside of the PHY to achieve the <300ms target, even in a point-to-point system. Assuming implementations would not take advantage of available standards and technology to meet these system performance targets in the coming years seems unnecessarily pessimistic. That is why I said the 1 second calculation (the result, not the calculation method) is unnecessarily pessimistic, but I should have worded that differently.
Hi Dongkok,
Thanks for sharing your thoughts on the boot process and ordering, that is good information to consider.
Best Regards,
Scott
-----Original Message-----
From: Kamal Dalmia <kamal@xxxxxxxxxxxxxx>
Sent: Friday, October 4, 2024 9:34 AM
To: 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
Dear Dongkok,
Thank you for your valuable input.
Dear all,
I agree with Dongkok, Ed and several others that the recall news is not relevant to 802.3dm.
May I suggest that the group move beyond this particular news and start talking about other important topics.
A key topic I would like to start discussing is PAM levels – especially for 5G and 2.5G speeds.
Regards
Kamal
From: 김동옥 책임연구원 전자선행설계팀 <DOKIM@xxxxxxxxxxx> Date: Friday, October 4, 2024 at 8:46 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx <STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Real live example of why latency maters
CAUTION: This email is from an external origin!
Hi TJ Houck
I don't think your explanation is wrong, and I agree that you are talking about an important topic for 802.3dm.
I just don't think the Tesla recall and 802.3dm have much to do with it.
I'll also share my thoughts on the booting you mentioned, but please understand that there are many OEMs and they have different system implementations, and my company has different implementations, so please take my story as an example and not representative of anything.
I think you should let the deserilizer system boot before the camera with serilizer. A system with a deserilizer, for example, the head unit, is pre-booted by the vehicle access or intrusion detection system. Once booted, it is expected that the cameras will be powered up (e.g. via power over coax) and booted in the same order.
The camera may be powered after the headunit has booted up, or the headunit may decide to do so. It depends on the features you want to implement in your system. If the headunit decides to power the camera, the DES side will start when the headunit has booted up. If the Headunit AP and the camera are powered together, the boot time of the Headunit AP will be much larger than what we are discussing and normal video transmission will not occur.
I apologize if I am understanding the problem incorrectly.
Also, I didn't mean to imply that what you said about latency was wrong, my English is not good enough and I apologize for misunderstanding.
Thanks for your contribution
Best Regards
Dongok Kim
From: TJ Houck <thouck@xxxxxxxxxxx>
Sent: Friday, October 4, 2024 9:20 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Real live example of why latency maters
Hi Dongok and Scott,
@김동옥 책임연구원 전자선행설계팀<mailto:DOKIM@xxxxxxxxxxx> – Tesla has been using GMSL and FPD-link for over a decade now for their camera feeds. They have FSD and camera teardowns you can publicly find or pay for online to prove this. How do systems boot today for the camera feed? The diagram in slide 8 shows how the latency numbers are achieved minus the processing information on the SoC. The diagram I put together is very similar to the ones many Tier 1s and OEMs use today to estimate the impact on time to boot. Can you explain why you don’t think what I showed relates to how boot latency times are explicitly calculated for the link we provide? @Scott.Muma@xxxxxxxxxxxxx<mailto:Scott.Muma@xxxxxxxxxxxxx>: I assume you did not attend the Hamburg conference virtually as all your questions were answered to the scenario you mentioned. Several people talked about byte-wise vs bulk transfer and its pros and cons. Slide 9 in my presentation shows how updates occur to camera sensors, making bulk transfer difficult due to how the data is processed in some scenarios. Several of the cons we discussed of bulk transfer will need to be addressed. On top of that, 1722 I2C bulk transfer has yet to be released as a standard and has not been implemented in any production vehicles today. As we all know, automotive customers take time to adopt, especially for safety-critical applications. This is why minimizing changes to the system is essential. I showed byte-wise because this is what is in production vehicles today, and I outlined several reasons for this while giving my presentation. Having both modes and using bulk for initialization could be beneficial once it gets proven out – because I outlined that there are cons to bulk transfers. I would also be interested in how you concluded: “The 1 second impact TJ calculated on slide 8 seems to be unnecessarily pessimistic.” The scenario I outlined is a real case scenario I came across in my career that I shared with the group. I mentioned during the presentation imagers can exceed this number of registers.
Best Regards,
TJ Houck
From: 김동옥 책임연구원 전자선행설계팀 <DOKIM@xxxxxxxxxxx<mailto:DOKIM@xxxxxxxxxxx>> Sent: Friday, October 4, 2024 2:00 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Real live example of why latency maters
Dear ALL tp-111-v01-final_tag. pdf (nhtsa. gov) , FMVSS Does this have anything to do with the latency that we are discussing in the FMVSS? I don't think so. The flow of the mail could be misinterpreted as a signal that a back screen of 2sec or
Dear ALL
tp-111-v01-final_tag.pdf (nhtsa.gov)<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nhtsa.gov_sites_nhtsa.gov_files_documents_tp-2D111-2Dv01-2Dfinal-5Ftag.pdf&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=-SBMIAARGisS7oqXYetVtOxipA5AwRxqEYovfCunqxdKIEAyhP-gquVqbR4fmZeU&s=u3KOWCHjx5Ws8U9UIqvALkQFfc232eAkFMH0rcJ6c4E&e=>, FMVSS<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fsa-3Dt-26rct-3Dj-26q-3D-26esrc-3Ds-26source-3Dweb-26cd-3D-26ved-3D2ahUKEwiq9vb8g-5FSIAxVKj68BHbWmDDcQFnoECBQQAQ-26url-3Dhttps-253A-252F-252Fwww.federalregister.gov-252Fdocuments-252F2019-252F10-252F10-252F2019-2D22036-252Ffederal-2Dmotor-2Dvehicle-2Dsafety-2Dstandard-2Dno-2D111-2Drear-2Dvisibility-26usg-3DAOvVaw1-2DEko1VDqFi-5FQn-5F2w2Pade-26opi-3D89978449&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=-SBMIAARGisS7oqXYetVtOxipA5AwRxqEYovfCunqxdKIEAyhP-gquVqbR4fmZeU&s=opWBqOcs80oRq_HV_XvAI8pN1EUPD-kSGUik2R3rWrQ&e=>
Doesthis have anything to do with the latency that we are discussing in the FMVSS? I don't think so. The flow of the mail could be misinterpreted as a signal that a back screen of 2sec or less is acceptable. In any case, 'no data' from the camera is not allowed. Is Tesla's recall relevant to this discussion? Tesla probably didn't use an LVDS camera, which would have met the latency requirements we're talking about, so why did it happen?
Thanks for your contribution
Best Regards
Dongok Kim
From: Ragnar Jonsson <rjonsson@xxxxxxxxxxx<mailto:rjonsson@xxxxxxxxxxx>>
Sent: Friday, October 4, 2024 9:40 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Real live example of why latency maters
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<mailto:Scott.Muma@xxxxxxxxxxxxx> <Scott.Muma@xxxxxxxxxxxxx<mailto:Scott.Muma@xxxxxxxxxxxxx>>
Sent: Thursday, October 3, 2024 4:45 PM
To: Ragnar Jonsson <rjonsson@xxxxxxxxxxx<mailto:rjonsson@xxxxxxxxxxx>>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto: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
From: Ragnar Jonsson <rjonsson@xxxxxxxxxxx<mailto:rjonsson@xxxxxxxxxxx>>
Sent: Thursday, October 3, 2024 3:41 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto: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 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0924_Houck-5FFuller-5F3dm-5F03-5F0917.pdf&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=CgyBrc_Y1KqLgOUX2mq7hG831UKXr6WA11Ub0eZPEYc&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0924_Houck-5FFuller-5F3dm-5F03-5F0917.pdf&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=hiHgBSUj2X0k3TORVxe0NCZAlJs6SEDHhwLDz5m9MbY&m=cQjU0XlwEjvcyjUTxtvLFLA08ZWnG28V1qe3fMEIHEgUXhKCmRZCk4lqRG0sJ-pt&s=DVju197kJP6q-IGD9zSqaRplMnmwX-FZk20RHkYWRWI&e=>
Lookingmore 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0924_jonsson-5Frazavi-5F3dm-5F01-5F09-5F15-5F24.pdf&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=XnaeMU8nNOffVS2rCm56DbTTYZTvY_tTdKUFocyZrfY&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0924_jonsson-5Frazavi-5F3dm-5F01-5F09-5F15-5F24.pdf&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=hiHgBSUj2X0k3TORVxe0NCZAlJs6SEDHhwLDz5m9MbY&m=cQjU0XlwEjvcyjUTxtvLFLA08ZWnG28V1qe3fMEIHEgUXhKCmRZCk4lqRG0sJ-pt&s=QSqAMwuvxOkKceJcoFVf5UunUE50S8elxbBhS-99X8E&e=>).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
From: Amir Bar-Niv <abarniv@xxxxxxxxxxx<mailto:abarniv@xxxxxxxxxxx>>
Sent: Thursday, October 3, 2024 2:00 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] [EXTERNAL] Re: [802.3_ISAAC] Real live example of why latency maters
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0924_Houck-5FFuller-5F3dm-5F03-5F0917.pdf&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=CgyBrc_Y1KqLgOUX2mq7hG831UKXr6WA11Ub0eZPEYc&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0924_Houck-5FFuller-5F3dm-5F03-5F0917.pdf&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=hiHgBSUj2X0k3TORVxe0NCZAlJs6SEDHhwLDz5m9MbY&m=Av0_xonJvFwdpdb-cJ8sw-DzM7SzQvYT9F6-PsRmWpXlvS-OE2agFkCI6efbDdnd&s=DFsddlQXA20xvxfk10cI8lCsTaMPce6t8ubi66xAAsw&e=>(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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0724_matheus-5Fdm-5F02b-5Flatency-5F07152024.pdf&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=i8M1nkI7wGlxMZWl7yZSbtADlBjBZ8Top5dwYZhngJM&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0724_matheus-5Fdm-5F02b-5Flatency-5F07152024.pdf&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=hiHgBSUj2X0k3TORVxe0NCZAlJs6SEDHhwLDz5m9MbY&m=Av0_xonJvFwdpdb-cJ8sw-DzM7SzQvYT9F6-PsRmWpXlvS-OE2agFkCI6efbDdnd&s=Rg9eo5xGnDcFk7YvcoCczndlEf8KaHkUK8359Cr2NLk&e=>(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
From: Mehmet Tazebay <00002b0d1a6e9d74-dmarc-request@xxxxxxxxxxxxxxxxx<mailto:00002b0d1a6e9d74-dmarc-request@xxxxxxxxxxxxxxxxx>>
Sent: Thursday, October 3, 2024 1:24 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: [EXTERNAL] 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
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0924_Houck-5FFuller-5F3dm-5F03-5F0917.pdf&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=CgyBrc_Y1KqLgOUX2mq7hG831UKXr6WA11Ub0eZPEYc&e=<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=>
Thisslide 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.cnn.com_2024_10_03_business_tesla-2Dcybertruck-2Drecall-2Doctober-2D2024_index.html&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=AZZ2H6wMh19GUMK208SAJVgtK3kLpdobULBjy-mD7cg&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__www.cnn.com_2024_10_03_business_tesla-2Dcybertruck-2Drecall-2Doctober-2D2024_index.html-26source-3Dgmail-2Dimap-26ust-3D1728573952000000-26usg-3DAOvVaw32-2DUs42D-2DZmcQOOVbrXpHc&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=tCrSND_CNffPG3UaWzQ-fIraqUuyA2tWycB6is5_QUw&m=74nQ2HELdw0p8wWAy026jHCdqKf4eRiqgkoYpObha215Em5ZVJiqug7_X6FLCktF&s=pu_soIHrUV2EJkkM0kZCztL_STHhlGJV70Yx1kw7v1s&e=>:
“Therearview display might appear blank for up to 8 seconds when the Cybertruck is put in reverse, according to a filing<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__static.nhtsa.gov_odi_rcl_2024_RCLRPT-2D24V718-2D2751.PDF-26source-3Dgmail-2Dimap-26ust-3D1728573952000000-26usg-3DAOvVaw1RMU-5FOfj2i6f082HWjXlrW&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=tCrSND_CNffPG3UaWzQ-fIraqUuyA2tWycB6is5_QUw&m=74nQ2HELdw0p8wWAy026jHCdqKf4eRiqgkoYpObha215Em5ZVJiqug7_X6FLCktF&s=ErfbJLLknRP1YbNgv-Czfs7GqVATryWADyGxpX1gy5E&e=>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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ieee802.org_3_dm_public_0924_Houck-5FFuller-5F3dm-5F03-5F0917.pdf&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=CgyBrc_Y1KqLgOUX2mq7hG831UKXr6WA11Ub0eZPEYc&e=<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=tCrSND_CNffPG3UaWzQ-fIraqUuyA2tWycB6is5_QUw&m=74nQ2HELdw0p8wWAy026jHCdqKf4eRiqgkoYpObha215Em5ZVJiqug7_X6FLCktF&s=6FQR4bk_n6xqdjrQ4R26mrbJjMRx53zPt_AsFWgllMY&e=>
Ialso 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://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwQFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=tCrSND_CNffPG3UaWzQ-fIraqUuyA2tWycB6is5_QUw&m=74nQ2HELdw0p8wWAy026jHCdqKf4eRiqgkoYpObha215Em5ZVJiqug7_X6FLCktF&s=-x8bsJp5G9KEsle3_YaGU2ohyXQI7xgWvUPEx4ooZHE&e=>
________________________________
Tounsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwQFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=hiHgBSUj2X0k3TORVxe0NCZAlJs6SEDHhwLDz5m9MbY&m=Av0_xonJvFwdpdb-cJ8sw-DzM7SzQvYT9F6-PsRmWpXlvS-OE2agFkCI6efbDdnd&s=5cAFo-tIHlZk7ZPFxihrDgxvCDFl69jeqKgG3sA9cCs&e=>
________________________________
Tounsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=hiHgBSUj2X0k3TORVxe0NCZAlJs6SEDHhwLDz5m9MbY&m=cQjU0XlwEjvcyjUTxtvLFLA08ZWnG28V1qe3fMEIHEgUXhKCmRZCk4lqRG0sJ-pt&s=XAdJgvZoPysQi3cGzbJceEC6BK2w52Dwh0TB6POGYVA&e=>
________________________________
Tounsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=-SBMIAARGisS7oqXYetVtOxipA5AwRxqEYovfCunqxdKIEAyhP-gquVqbR4fmZeU&s=1cbk751XeyT6lrQZo8ERz0F8F5N-SgfNQXHO_957YXs&e=>
________________________________
Tounsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwQGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=-SBMIAARGisS7oqXYetVtOxipA5AwRxqEYovfCunqxdKIEAyhP-gquVqbR4fmZeU&s=1cbk751XeyT6lrQZo8ERz0F8F5N-SgfNQXHO_957YXs&e=>
________________________________
Tounsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e= ________________________________
This email has been scanned for spam and viruses by Proofpoint Essentials. Click here<https://urldefense.proofpoint.com/v2/url?u=https-3A__us2.proofpointessentials.com_app_report-5Fspam.php-3Fmod-5Fid-3D11-26mod-5Foption-3Dlogitem-26report-3D1-26type-3Deasyspam-26k-3Dk1-26payload-3D53616c7465645f5fd078f80da23aaf77d9150103b6d14e33b9d415126b29bc40d0f1481c4fe2bd0299f1214da48a1bd29c2285052376de74e922561126065183413cec017d3a51f7929e98511d14fe8c313896415bba22508b5f915fc25e08e40d1c9503aa47f8d9ad05a89a882801a05b50bd49f0a5b09eace87fbdd1bff6dce84b2e3635ef95cc4c3123da69e6732d3eaf7d064fe29e6464f5dac9148d6bac&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=98Qjl61fwGe5snK8HFKbg-gr6Hii_FXxQ2rnONiXORk&e=> to report this email as spam.
________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e=
________________________________________________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e=
________________________________________________________________________
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2DISAAC-26A-3D1&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=J1SA7HOg3eMkZ4Ta2uMjVDFua3unSZMjc_DFB_Uwiu8&m=uhwN2-xhRQFr5HDY44-P2qG-5rbGaLh5Jca5bUxGm64Ksj-9Oua4gUNcI7lVdIiM&s=5FKdf3iRMrPUmC6Q8DjndewZ_n5NqACd-QyltDkXBgw&e=
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 |