| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I am willing to start such a discussion group on the best way to implement FEC. To date, FEC implementation, although discussed during specific FEC presentations, has not been discussed in a formal discussion group because most of the effort to date has gone into "proving" that FEC, for the cost, will indeed be worthwhile for EFM.
I believe there is now enough technical information to predict with confidence the performance improvement expected from FEC and that it is worth the cost. I plan to summarize this information at the Edinburgh meeting. Hopefully, there will be enough support in Edinburgh to pass a motion in support of adding FEC (or at least support to go forward with FEC) and then we can get down to the nitty gritty implementation details. Vipul, Wael, is this a reasonable approach to take? I would expect such a discussion group to be populated with individuals that can, and are willing , to contribute positively to the FEC implementation details.
Regards,
Larry
FEffenberger@xxxxxxxxxxxxxxxxx wrote:
Larry, First of all, I am a supporter of FEC, and think that we should continue working on it. However, I would not favor moving the FEC topic out of the optics track. The primary application of FEC is to make up for shortcomings in the optics. Therefore, where better to discuss it than the optics track? There is no doubt that FEC will be located inside the PHY layer, and not in the MAC layers (it is unfeasible, otherwise). Hence, the optics track is where it belongs. Regarding the priority of FEC inside the optics track... regrettably, there are some very important issues that have yet to be solved (the P2P wavelength choice being the most obvious one). While these other issues rank higher than FEC, I, for one, do not believe that that will rule out the inclusion of FEC in the standard, pending a full examination of the evidence. I'm sure that Vipul would agree with this basic approach. The task force chair is occasionally emphatic at times about "baseline now!" and "minimum number of PHYs!", but I do not believe it is the chair's intention to throw out valid topics of consideration purely on the grounds that it doesn't fit his schedule. The IEEE process has no pre-ordained schedule. If it takes an extra meeting, then so be it. On the actual work, what I've seen is that there have been two proposals regarding the application of FEC. I authored one, and Lior from Passave authored the other. On their face, they both use the same base code, RS(255,239,8), and promise the same sort of performance boost. The differences between these two systems has to do with how to protect the framing control codes, and how to insert the parity symbols. I have been looking forward to a conversation regarding these issues, but to date nobody has offered to organize such a thing. We should start this soon, with the goal of reaching a more coherent picture by mid-summer. Sincerely, Frank Effenberger.-----Original Message-----FEC needs a good home with EFM for discussion purposes. Right now FEC is being discussed in the optics track but it has the least priority. Is this still the correct track ? As has been presented in several previous presentations, FEC can reasonably be added just after the GMII interface. Therefore, it is a valid consideration for discussion issue within the EFM TF. As some have said, "if the payload warrants FEC let the upper layers decide on whether or not to include FEC". I don't believe this is the correct way to treat FEC for EFM. The addition of FEC can bring substantial benefits to our EFM standard. These have been discussed in prior presentations (increased range, link quality monitoring, relaxation of BER spec for PMD, etc.).
From: larry rennie [mailto:Larry.Rennie@xxxxxxx]
Sent: Wednesday, May 08, 2002 1:04 PM
To: stds
Subject: [EFM] FEC needs a good discussion home!
Regards,
Larry