| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Data on rates is also good, but it isn’t really the same thing. The two discussions are different, which, in my mind, changes at what stage such data is needed: Specifically, the data rate discussion is about PAR scope, which limits what we discuss in task force – this is a discussion of “who broad can we go”.
The length discussion is about an objective – what is the “minimum acceptable performance” for a specification. This doesn’t limits how far we can go, but does limit how far we must go to meet our stated need.
I think we have consensus that at least our scope and our objectives should include rates of up to 100 Mbps in the slow direction and 2.5Gbps, 5Gbps, and 10 Gbps in the fast direction. Beyond that, I think we need to build consensus.
We have seen data on the camera market that supports a broad need for those rates. We have seen point-data that goes beyond that; however, and I, at least, would want to see more before adopting objectives. To do that I, at least, need to understand more
– I would want to consider the impact on the specification development (which could be minimal, or could be medium – I don’t see a case where it is large) and the impact on the complexity of the phy speeds in the consensus bulk of today’s market vs. the sizing
and timing of the opportunity for expansion of the applicability of our standard to serve a growth in the market in speed. For what it is worth, as far as I know no one has proposed objectives committing us to specify a rates of 25 Gbps, and I believe that Kirsten & I would agree we need see more market data/estimates, market timing, and estimates of the technical
impact on the specification before accepting such an objective. I’d similarly want to such data before supporting an objective of greater than 100 Mbps in the other direction. I’d suggest focusing on the length (or loss) because getting to some consensus
on this will help us to get the data on technical impact of speeds. -george From: Kirsten.Matheus@xxxxxx <Kirsten.Matheus@xxxxxx>
Hello George, yes, I agree that the project should look at the majority of use cases and not to include all possible exceptions. For length as well as for data rate. Solid market data is welcome in both cases and I would welcome contributions that made
the effort to present more data. Kind regards, Kirsten p.s. here is another early presentation that addresses link length
https://grouper.ieee.org/groups/802/3/RTPGE/public/may12/hogenmuller_01_0512.pdf Von: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Dongok & Kirsten – Thank you for this information, but I do not share your conclusion. These are single point examples. I will point out that the buntz presentation pointed to earlier contains single point examples out to 20m and more. The problem with
this approach is confirmation bias - you can always find a length that fits your assumption of what you want the reach to be. Length is problematic for our specifications. We generally need it when it relates to propagation delay, otherwise what we really need is loss. Some standards have set objectives based on loss at Nyquist, and that might be a way of avoiding
the whole ‘length’ problem – as well as the arguments that ensue once the standard is published and someone wants to go longer, for example, using a special cable. See,
https://www.ieee802.org/3/da/public/0923/zimmerman_3da_01_0923.pdf for a discussion of this. I have seen some backplane PHY objectives (see 802.3ck) specify loss at a generally
agreed upon frequency (although they seem not to do this with cables), and that might be useful – especially as it removes the whole media type discussion. However, if we choose to go the “length” route, I reiterate, we need to look at the broad industry data and not single point examples – otherwise we really don’t know how much extra market we are including for what phy designers know is
extra pain. I submit that this is CORE to the charter of the task force, which was to look at phys OPTIMIZED for automotive end-node cameras. Supporting length (or insertion loss) beyond a well-established market need will almost surely not be optimized.
And the only way to get a well-established market need is to get market data on the distributions of lengths needed.
So, how can we get this data? One way to get the data might be from someone who is familiar with the supply chain and/or testing of cable harnesses across the industry should have a broader view. This data would likely be considered highly
proprietary, and even more proprietary would be information on the segments of the vehicle market served. However, without understanding the segment of the vehicle market served by the suppliers in the data set, it would be difficult to validate. Therefore,
I don’t recommend this (but wouldn’t object if someone has data – more data is good…) The segment of the market served, I believe, is key. This is because the maximum possible cable length needed is going to dependent on the type/size of vehicles that we wish to include in the application space for ISAAC. Data on the number
of vehicles (or number of cameras into vehicles) by vehicle type/size would be very instructive. While electrification is changing the size of vehicles, oddly making both larger and smaller vehicles at the same time, the needs of people, and the width of
roads are generally slower to change. We can get estimates from today’s data. Such data must necessarily exist, as vehicle size class is specified and categorized by many governments as well as safety and insurance associations for fuel economy, safety,
and other purposes. (see, e.g.,
https://en.wikipedia.org/wiki/Vehicle_size_class ). We might have to approximate from volume to dimensions, but I suspect that can be done, as the dimensions are constrained by width, stability (not too high), and other factors. Without looking across the application space, we can pick as large or small a vehicle as we want and get the answer we want, and we need to avoid getting enamoured with single point numbers. Otherwise, I might pick a small bus or tram,
which the buntz presentation tells me needs 20-25m. We get caught in a creeping upward spiral and arguments about whether a particular size is common or rare – without data. Given vehicle size data, it is relatively straightforward to get an (over)estimate of cable length in the non-zonal case. But, if we wanted to include vans similar to the ‘sprinter’ vans in the buntz presentation (sorry, I don’t know the
generic name). Buntz states 15m for these. Note that if we wanted to efficiently serve passenger cars, the answer would likely be less, as these vehicles are notably smaller. Discussions during 802.3cy with individuals from the automotive industry suggested
a worst-case run might go front corner to rear compartment, and run the width of the vehicle twice, and the length, and some factor for vertical displacement. By example, A large sprinter is 290in long x 170 wheelbase x 114 high – going either across twice
OR up & down twice, once in the other direction, and running the entire length, I get about a total of 18.8m (290in + 340in + 114in = 744 in) – consistent with the 15m buntz stated – about 23% over. If we consider a fraction of the high note that the height
here includes the height off the road, and the ECU isn’t likely located in a corner anywhere… it is an overestimate even of the worst case, and I would suggest using 75% of that routing dimension as a good proxy. It might be useful to see a passenger car
example, as the sprinter van is unusual in its height, possibly skewing the percentage. Even so, the entire nature of zonal architecture is to get rid of these “front corner to rear corner compartment” links which criss-cross the vehicle and run its length, so it will be an overestimate for the future. Will it happen? – yes.
but the opportunity is for us to make an optimized link with lower power and cost, and we are missing it. In this regard, many of us in the PHY world have seen PHYs designed for a particular worst case architecture (e.g., structured cabling’s 100m) become
OBSOLETE before getting significant market purchase because the industry shifted architecture enabling substantially reduced design specifications (e.g., top-of-rack data center links of 15m). Therefore, we need to keep an eye on when we expect intersection
with zonal trends and not just plan on the longer links fitting into the zonal links. Ultimately, we as a task force, need to make a judgement on what segment of the market we are serving. Hopefully this gives all some food for thought and we can find ways forward. To repeat myself (because there’s a lot here) – we can avoid the ‘length’ discussion entirely and focus on loss, or we can try to get market data across a variety of vehicles. Single-point examples aren’t going to feed good decisions,
except for those single points. We may also wish to get some market data on expectations for the timeline of zonal designs… Fortunately, now we have time. -george 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 |