Dear Kirsten,
I just reviewed your recent analysis of latency requirement and performance for different PHY schemes
https://www.ieee802.org/3/dm/public/0724/matheus_dm_02a_latency_07152024.pdf
Thank you for the detailed analysis, especially the clear discussion of how latency impacts imager system as a whole in actual application (page 9/10). I have the following comments regarding the assumptions made.
Periodic wake up schedule
In slide 21/22, you start from the assumption that the full duplex 802.3ch PHY would use a periodic schedule as follow:
“The most power is saved when a 1500-byte payload US packet is sent every 123.36us. Shortening the packet reduces the latency but also the power that can be saved”
However, because EEE allows on demand wakeup, there is no need to pre-arrange a periodic wake up schedule as you highlighted. Instead, the wakeup intervals will dynamically adapt to the uplink traffic usage.
In fact, the spec mandates the worst-case time delay between a request to transmit data at the XGMII interface to the time data is transmitted (table 78-4 of 802.3ch) to be:
Therefore the worst case latency for EEE in the uplink direction would be:
PHY delay (8.96us/S, fast wake mode) + packet delay
This number to first order does not have to tradeoff with power efficiency of the 802.3ch PHY serializer. This is because typical camera uplink traffic consists of bursts that happen roughly every frame. The uplink would stay in LPI for
the vast majority of the time (on the order of 99%) due to lack of uplink data in the case of 802.3ch with EEE (and some autonomous EEE scheme).
There are other conclusions from the slide which would not follow once we consider real life traffic patterns. For example, the following statement (slide 24) does not apply to typical camera traffic
“When applying EEE for the DS the same assumption applies as in the FDX/EEE US case: The link should be quiet 50% of the power saving time. Also there is a minimum quiet time, which needs to be observed.”
In the downstream direction, the traffic is steady image data with frame blanking gaps on the order of 1ms. For power savings in the downstream direction, the 802.3ch EEE could go to LPI during those milliseconds gaps, without any significant
latency hit. Obviously because frame blanking intervals are usually a small fraction of the overall image frame (10-30%), this is a second order power saving mechanism. In real life 802.3ch sensor PHY, just going to LPI in the uplink provides competitive
power numbers to incumbent serdes serializers.
It is therefore difficult for me to come to the same conclusion you have which is:
“With power saving in the DS, the packets are best sent in a bulk. This almost levels all differences between the duplexing methods DS, with TDD being somewhat more flexible”
In fact, with real life consideration in mind it actually follows that 802.3ch with EEE is more flexible than ASA’s TDD. Unlike TDD, 802.3ch EEE does not have to tradeoff power efficiency and uplink latency.
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