| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Kirsten: “However, how would you handle it if you only needed to transmit a camera video stream of 6 Gbps, while you have 10 Gbps link rate available. Would you want to use EEE to
also safe power or rather send continuously filling the capacity with idle/alike?” As far as I know, whenever you are proposing a discrete set of gears, speed modes, whether TDD, FDD or other, there is potential that some bandwidth is unused. In the case of 802.3ch, there is indeed a discrete set of speed modes/gears (2.5/5/10), and same with ASA TDD scheme. In both cases, you can choose to run at the next gear if the payload exceeds a given gear,
and both schemes would have extra bandwidth available. EEE allows additional power savings downstream, but it doesn’t mean it has to be enabled if the extra power saving is negligible. 802.3ch sensor PHY can achieve < 200mW at 10Gbps downstream (ref: slide
6
https://www.ieee802.org/3/dm/public/0524/Evaluation%20of%20802.3ch_Tran_050142024a.pdf), without enable LPI transitions downstream, so in practice it is not necessary.
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Kirsten – not sure what existing parts you are referring to, but the basic protocol for EEE is asymmetric – it works independently in both directions. LPI quiet/refresh is entered or exited from each direction
by itself. So, if the existing parts are built according to the standard, they would handle the asymmetry. As to the 6 Gbps, case, this sounds like a case for a trade between power & area – you might save buffer and not go into quiet/refresh, or you might save power and use buffering. Similarly to other phys when
the rate doesn’t match if you have power saving modes… George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 From: Matheus Kirsten, EE-352 <Kirsten.Matheus@xxxxxx>
Hello Yunteng,
Yes, EEE can be done independently in UL and DL direction and you do not have to implement it on the camera side. However, how would you handle it if you only needed to transmit
a camera video stream of 6 Gbps, while you have 10 Gbps link rate available. Would you want to use EEE to also safe power or rather send continuously filling the capacity with idle/alike?
Also, in many discussions I had, there was a desire to reuse existing parts. They would have EEE in both directions. However, if you make extra parts, it would be desirable
to optimize. Of course. Kind regards,
Kirsten Von: Yunteng Huang <yunteng@xxxxxxxxxxxx>
Dear Kirsten, Kamal,
Thank you for your contribution on buffering analysis:
https://www.ieee802.org/3/dm/public/0724/matheus_dalmia_dm_03_buffering_07152024.pdf
In slide 12 of the presentation, you write that an FDX/EEE (802.3ch) would
need “Normal MAC buffers (esp. pause), wake time buffers for min 9us @ high rate” on the camera side. An implied assumption here is that 802.3ch based camera system would go in and out of LPI for power savings in the downstream direction
analogous to TDD scheme. In practice, frequent entering/exiting LPI is not needed in the downstream direction thanks to FDX. If you leave the downstream direction active and only enter/exit LPI in the upstream direction, which is a rational use of EEE for
this application, there would be no need for wake time buffers at high rate on the camera side.
Sincerely, Yunteng Huang 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 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 |