Re: [802.3_ISAAC] About Latency and Power of 802.3ch EEE

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

All,

I agree with Ky-Anh’s comments below.

I also agree with Ky-Anh’s comment on https://www.ieee802.org/3/dm/public/0724/matheus_dm_02a_latency_07152024.pdf

that was posted earlier today.

There also appears to be some misconceptions about 802.3ch EEE in https://www.ieee802.org/3/dm/public/0724/matheus_dalmia_dm_03_buffering_07152024.pdf,

where it appears to be assumed that if EEE is enabled for upstream, then it also has to be enabled for downstream.

I wonder if it would be beneficial for the 802.3dm group to get a short tutorial on how 802.3ch EEE works, given that there are clearly some misconceptions about it.

There is considerable knowledge about how 802.3ch EEE works in in the 802.3dm taskforce. My estimate is that all-in-all the participants regularly attending 802.3dm have worked on at least 5 separate 802.3ch implementations. It might make sense for some of the 802.3ch experts to put together a short tutorial on 802.3ch EEE.

Ragnar

From: Ky-Anh Tran <kyanht@xxxxxxxxxxxx>
Sent: Tuesday, July 16, 2024 7:26 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] Re: [802.3_ISAAC] About Latency and Power of 802.3ch EEE

Dear Steve Kang, Steve Gorshe, Since tomorrow’s meeting has constrained time for questions/follow up, I would like to follow up with you with respect to clarifying a detail in your presentation: https: //www. ieee802. org/3/dm/public/0724/kang_3dm_01a_2407. pdf

Dear Steve Kang, Steve Gorshe,

Since tomorrow’s meeting has constrained time for questions/follow up, I would like to follow up with you with respect to clarifying a detail in your presentation:

https://www.ieee802.org/3/dm/public/0724/kang_3dm_01a_2407.pdf

On slide 11, you mention that for the Power Saving feature:

“EEE can be activated 1 sec after full duplex Transmission”, as opposed to ASA MLE which is “always active”

Could you clarify how you obtained the 1 sec minimum time after full duplex transmission, after which EEE can be activated for a 802.3ch PHY?

My understanding is that the 802.3ch spec (section 149.3.6) says:

“PHYs with EEE capability have transmit and receive functions that can enter and leave the LPI mode independently. The PHY can transition to the LPI mode when the PHY has successfully completed training and pcs_data_mode is TRUE.”

The spec allocates 97ms (Table 149-15) for the full training process (only part of which is full duplex training), after which the PHY can enter LPI immediately, based on traffic availability. Actual silicon measurement shows that this time can be < 8ms, both of which is much lower than the quoted 1 sec.

https://www.ieee802.org/3/dm/public/0524/Evaluation%20of%20802.3ch_Tran_050142024a.pdf

From: Ky-Anh Tran <kyanht@xxxxxxxxxxxx>
Sent: Friday, July 5, 2024 7:16 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] About Latency and Power of 802.3ch EEE

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:

Time in full duplex in refresh during RX-LPI
Time in full duplex data mode.

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:

1 to 2 % full duplex time averaged over a frame time scale.
<40us uplink latency using slow wake mode.

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