| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ragnar, Max, I would also like to have more use case discussions, and appreciate your contributions so far. However, it would be useful to separate the behavior of specific implementations from the system/application
requirements. TJ’s presentation made latency/delay understandable through diagrams, however, I understood the presentation was describing the behavior of a specific implementation.
To take this to an extreme, if we hypothetically connect a processor directly to an imager we could observe the behavior of that implementation and it might “require” even lower latency because
of decisions made by the implementer even if the overall application has no direct requirement for such low latency. If we accept such requirements then there is no possible alternative but direct connection between camera and ECU.
Similarly, if we state that the requirements are precisely the observed behavior of a point-to-point connection, then connecting the camera to processor over a network may not be possible/economical.
I believe Kirsten tried to make this point in the call, and if there is no network possible then Ethernet may be burdening the solution to the point that it can’t even achieve the point-to-point case at similar cost/power/latency. So to Max’s point on the
call, I don’t expect anyone is against a solution that supports a networked topology (since that is the point of Ethernet), but overconstraining the valid solutions will prevent a networked topology. I would not yet claim that 10us switch->camera and 1us camera->switch are not the true requirements, but these requirements will severely constrain the valid solutions and I am concerned it will
take a networked topology off the table. Best Regards, Scott From: Ragnar Jonsson <rjonsson@xxxxxxxxxxx> EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Hi Max and all, At the end of yesterday’s meeting Max asked if we should have more Use-Case ad hoc meetings before the September meeting. There was a problem with my microphone, so you probably did not hear my comment. I think that we obviously need to
have more Use-Case ad hoc meetings before the September meeting. While yesterday’s ad hoc was a good start, we did not even have time to finish going over your proposed definitions of delay vs latency. Kirsten has already sent a follow-up email, highlighting the need for finishing that discussion.
I think that we need a deeper dive on the latency/delay requirements. There was a factor of 10 difference in the two proposed latency requirements presented in Montreal: Kirsten presented https://www.ieee802.org/3/dm/public/0724/matheus_dm_02b_latency_07152024.pdf On slide 3 it states “It provides concrete examples of latency and latency requirements in a camera system.” On slide 9 it states “Ethernet latencies of
10us in the DS and of 100us in the US are sufficiently small …” TJ presented https://www.ieee802.org/3/dm/public/0724/houck_fuller_3dm_01_0724.pdf On slide 9 it states “It is proposed to limit the latency to
10us worst case in the switch to camera direction and 1us worst case in the camera to switch direction.” TJ told us that these requirements are based on our conversations with multiple OAMs and with the ADAS SoC vendors. There are also other issues that were brought up in Montreal related to Use-Cases that need further discussion. In summary, we clearly need more Use-Case ad hoc meetings. 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 |