| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Brad, Thanks. So the scenario might be that some applications requiring ultra-low BER (e.g. FCoE) might move physical location, changing the requirements of links that are already established. It would clearly be a useful optimization to enable FEC only where such applications need it and gain the power/latency advantages elsewhere. Depending on the FEC choice, this may need handshaking etc. – would you think it might be sufficient to use a receiver-only approach if we go with a simpler FEC? Hugh. From: Brad Booth [mailto:Brad_Booth@xxxxxxxx] Hugh, Shorter answer: VMs & SDN. There is a trade-off between latency and BER with FEC. With virtual machines (VMs) and software defined network (SDN), there should be the ability for that trade-off to be made without being locked into a choice that is suboptimal. And yes, synchronization/hand-shaking would be required to make it work. Cheers, Brad From: Hugh Barrass (hbarrass) [mailto:hbarrass@xxxxxxxxx] Brad, One short question: What is the application that requires the FEC to be turned on/off after the link is established? The current assumption is that FEC should always be used if it is advertised as available. If there is a critical application that requires the FEC to be selectable without bringing the link down then it may have other knock-on effects - particularly if we choose a FEC that does not pass the data through unscrambled (with the parity block sent separately). Clearly, for a simple FEC (such as RS), the receiver can independently choose to use the parity block or not – allowing the receiver to save power or reduce latency if the BER is acceptable. Anything that requires a change to the transmitter will necessarily need some form of synchronization between the transmitter and receiver to ensure that the receiver doesn’t misinterpret the data stream after the change. Thanks, Hugh. |