| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I would like to address the question of whether 2.5GBASE-T needs link fault signaling. Like 10GBASE-T, the design of 5GBASE-T and 2.5GBASE-T is based upon the XGMII and associated Reconciliation Sublayer (RS) that performs link fault signaling
specified in 46.3.4.3. We should not remove this piece of the system without a thorough understanding of the consequences. Removing the requirement of link fault signaling at the RS will have undesireable consequences on 2.5GBASE-T. One example is the recovery from a fault during
EEE low power idle. xGBASE-T EEE low power idle mode is asymmetric and may be entered by one or both PHY transmitters. During LPI, the transmitters and receivers are powered down
except during short refresh transmit periods. The PHY must handle long periods without any signal at the receiver, but maintain extremely precise clock synchronization with the link partner as well as keep all of the adaptive equalizers and cancellers updated
for changing conditions. Should anything go wrong in the PHY receiver, link fault signaling provides the mechanism for recovery without dropping link and performing a multi-second link
retrain. A PHY with a receiver fault during LPI uses fault messaging to wake up the link partner transmitter and clear the fault in order to avoid a link drop. It sends
local fault toward the local RS. The RS responds by sending remote fault towards the link partner RS which responds by sending idle ( instead of LPI) into the link partner PHY causing the transmitter to wake up and transmit idle symbols to the near-end PHY
until the fault is cleared. Without fault signaling there is no other way to force the link partner to wake and transmit continuous signal for recovery without dropping link and retraining. I think it is necessary to keep fault signaling as a requirement in Clause 46. Regards, Brett From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx]
William, If the vast majority of people all agree that having 2.5G Ethernet (in all its various and future forms) support link fault signalling is the
right thing to do then fair enough. My concern is that this has slipped in un-noticed and people are not aware of the extra requirement. Also I am not sure that 2.5GBASE-T “needs” link fault signalling. My understanding is that it is unnecessary for 2.5GBASE-T but is required
for 10GBASE-T and possibly for 5GBASE-T. Arthur From: William Lo [mailto:williaml@xxxxxxxxxxx]
Hi Arthur, I would have preferred to simply take the 1G PCS, RS, and MAC and simply scale it to 2.5G. However 802.3bz chose to scale down 10G RS and MAC for 2.5G. I don't think it is a good idea to have RS attached to one kind
of PHY not support link fault signaling while supporting it in another when both PHYs are operating the same speed. Note that 802.3cb could simply scale down 10GBASE-R to 2.5G and avoided all this link fault signaling issue but didn't. We are aware of the scaled up 1000BASE-X solutions in the field for 2.5G and crafted something something
that will allow legacy solutions to be compatible (see annex 127B) and yet align to the decisions that 802.3bz task force has made. I do not think it is justified to ask 2.5GBASE-T to disable something that it needs simply for the sake that some legacy non-IEEE sped up version of 1000BASE-X, RS, MAC can't handle fault signaling. If there is a market
demand to connect up this legacy interface to 2.5GBASE-T there are vendor specific workarounds that can be applied. Thanks, William
|