| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Steve Kang, Steve Gorshe, Thank you for your detailed analysis of ASA’s TDD and 802.3ch PHY Latency and Power. I have read your latest presentation for July Plenary at this link: https://www.ieee802.org/3/dm/public/0724/kang_3dm_01a_2407.pdf and have some remarks regarding the assumptions made in the presentation. In your presentation, the fundamental assumption you use (slide 7) is as follow: “To compare ASA-MLE against IEEE 802.3ch, it is assumed that both schemes use a 30µs period for upstream transmissions.” From which it seems you conclude that a
“% of time when uplink is active (when 30us period is assumed)” (slide 10) for 802.3ch Sensor PHY would be
30.6%. However, it seems to be the wrong starting point. This is because 802.3ch EEE does not need to operate on a pre-determined schedule, unlike a TDD system. 802.3ch with EEE offers on-demand 10Gbps UL throughput, and does not need to wake
up every 30us in order to meet the uplink traffic profile and latency of typical camera sensors. Typical camera uplink traffic consists of control data (e.g. I2C) bursts, and frame sync signal, both of which happen at most once per frame. In a realistic
use case, the 802.3ch PHY would get woken up at most once or twice per frame based on data availability. This does not require pre-planning of a wake up schedule and can be handled autonomously by the ECU side PHY/MAC. The time the PHY spends in full duplex on the sensor side is:
The first part of the time is 1% of the time spent in RX-LPI. The second part depends on how often the link has to wake up, and how long the transmission lasts each wake up. Because 802.3ch with EEE transmits data uplink at 10Gbps * S
during a burst, the time spent awake is less than a few us’s. Because traffic to camera will wake up the uplink only at most once per frame, this happens every 10-30ms. This means the second part of the time is on the order of (<10us / 10-30ms ~ 0.1%).
The percent of time spent in full duplex is between 1-2% in practice, averaged over thermal time scales (10’s of ms).
A second remark I’d like to make regards the claim there is tradeoff between latency and power efficiency for 802.3ch “Increasing TX transmission period beyond 30us (~ 1ms) could improve the power saving efficiency for 802.3ch but also increases latency
• Intermittent transmission for tunneling I2C and GPIO (periodic shutter control) signal could bring challenges to existing camera system design” I would like to point out this tradeoff isn’t there with a realistic camera traffic profile. Because frame-sync and control signals are sent in burst at most once per frame, each time the ECU sends out data, the RX sensor PHY will wake
up from LPI. This incurs a latency which does not tradeoff/affect the % of time spent in full duplex described earlier. In fact, the Standard specifies this time to be about 30us/6us (10Gbps mode) for slow/fast wake mode.
In particular, I would like to point out that real life silicon measurement of 802.3ch sensor PHY in sensor camera module support the points made here which is:
These include the additional implementation dependent efficiency losses. Of course, there are improvements one can make to the Standard to further improve this but the marginal gains in a real life use case scenario become diminishing
after a certain point. 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 |