| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I’ve been going through the document thinking about what a change to the status of fast retrain would mean. Currently in the draft, support for Fast Retrain is optional.
In addition, it may be disabled by a bit (incidently, the bit is labeled enable – it only works that way if FR has already been advertised and negotiated). There are a whole bunch of places (I easily found 23) in the draft where “if the fast retrain capability is supported” or something like that is in the text, but that’s not the problem. The issue is that the way I see it, even on the new shielded cabling there will be some likelihood of leakage or other noise conditions leading to a desire for a fast retrain – so, in my opinion, it would be a bad idea to remove it completely. That leaves me with whether we make it mandatory or keep support of it optional. I was leaning towards mandatory support, but now am back to keeping it as it is, perhaps with a labeling change – I want to vet the thought prior to our PHY meeting, which is looking like 11AM-12 pacific time Thursday. Here is my reasoning:
-
IF FR were a mandatory capability, you would logically disable it when it is undesired.
there is a management “fr_enable” bit - the enable bit, right now, effects only one side and, as the note says, causes the link drop if the partner initiates a fast retrain.
-
One would like the ability to disable FR on a link basis, getting both sides to agree not to try
FRs. The advertisement in
autoneg of FR support is the currently defined way to do this. Therefore, in order to set a link most conveniently and reliably not to FR, you want to not advertise support for it in
autoneg. This is equivalent from an interoperability standpoint of working with PHYs that do or do not support
autoneg. The easiest solution is to leave FR as it is, and perhaps add a note that implementation of FR is recommended, and using the ‘FR supported’ bit in
autoneg is the recommended method for disabling it. Alternatives if FR is a mandatory capability are:
- editorially change the meaning and language around the many places where FR support is mentioned to say, for PHYs that have FR enabled, and change the function and
meaning of the FR enable bit in 40G to be a true enable and add a note that autoneg FR support be set to reflect this bit.
We could then also get rid of the FR supported status bit. Please consider and be ready to resolve this in the PHY meeting – also, look for the announcement. Probably tomorrow. George Zimmerman Principal, CME Consulting Experts in Advanced PHYsical Communications Technology george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx 310-920-3860 (PLEASE NOTE NEW EMAIL ADDRESS.
THE OTHER WILL STILL WORK, BUT PLEASE USE THIS FOR CME BUSINESS) |