RE: FW: [EFM-P2MP] FW: [EFM] EFM FEC Proposals
Howard,
One function of the disparity rules is to look for errors.
In case of no FEC, disparity error means wrong bits.
In case of no FEC, disparity error does not mean wrong bit, since FEC
can correct it (in F-FEC). (and lot of errors are expected before FEC).
Therefore, dealing with FEC should be done in a different way:
1. Not check for disparity errors.
or
2. Start with 8/10 decoding (with no disparity check), then go
to FEC decoding, then make 8/10 encoding again and
then look for disparity errors.
This is the way I see it.
Raanan
-----Original Message-----
From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On Behalf Of
Howard Frazier
Sent: Friday, July 05, 2002 2:13 AM
Cc: stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx;
stds-802-3-efm@xxxxxxxxxxxxxxxxxx; 'stds-802-3-efm-p2p'
Subject: Re: FW: [EFM-P2MP] FW: [EFM] EFM FEC Proposals
Raanan,
why is the disparity checking function affected differently from any of
the other 8B/10B coding rules? Perhaps I am missing something, so I
would like you to elaborate, perhaps providing a brief example of a
scenario that you think would cause trouble.
Howard
Raanan Ivry wrote:
>Howard,
>It sounds reasonable.
>But the disparity check functionality is different
>than in old systems (because of the high BER). Is it?
>Raanan
>
>-----Original Message-----
>From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
>[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On Behalf Of
>Howard Frazier
>Sent: Thursday, July 04, 2002 7:44 PM
>To: stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx;
>stds-802-3-efm@xxxxxxxxxxxxxxxxxx; stds-802-3-efm-p2p
>Subject: Re: [EFM-P2MP] FW: [EFM] EFM FEC Proposals
>
>
>
>
>Raanan,
>
>regarding your point # 1, this would represent a link
>that was operating outside of the specification. If you don't have FEC
>at both ends of the link, then the link must comply with the budget for
>non-FEC enabled links. The behavior in the region beyond the limits of
>the link budget is unspecified.
>
>Another way of saying this is that a link comprising PHYs without FEC
>either end will have a budget of X dB, and will have a BER of Y or
>better as long as the link loss + penalties is less than or equal to X.
>
>A link comprising PHYs with FEC at each end will have a budget of
>X+delta, and will have a post-FEC BER of Y or better as long as the
>X+link
>loss + penaties is less than or equal to X+delta.
>
>Operation of a link comprising "old" PHYs (without FEC at each end,
>and) with a link loss + penalties of greater than X dB is outside the
>scope of the specification, just as it has always been.
>
>At least, that's the way I see it.
>
>Howard
>
>Raanan Ivry wrote:
>
>>Lior,
>>Some comments:
>>1. Compatibility.
>> When an old system receives FEC protected frames it will detect
>> disparity errors (because of the low power). How will the old
>>
>system
>
>> deal with it?
>>2. Error duplication.
>> In both schemes you can correct 8 symbols. 8 or 10-bit symbols.
>> The error probability of 10-bit symbol is higher, therefore the
>>performance
>> of the S-FEC is better for AWGN.
>> 80 bits burst protection is not required, so this is not an
>>argument. 3. Byte and frame alignment.
>> In upstream you have the preamble and delimiter so additional
>> alignment is not required.
>> In downstream, since the sync byte is always in the beginning of a
>> fixed length frame, alignment is very robust (and was proven in lot
>> of standards).
>>
>>Best regards,
>>Raanan
>>
>>
>>-----Original Message-----
>>From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
>>[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On Behalf Of
>>Lior Khermosh
>>Sent: Wednesday, July 03, 2002 7:29 PM
>>To: Ajay Gummalla; Larry Rennie;
>>stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx
>>Cc: stds-802-3-efm@xxxxxxxxxxxxxxxxxx
>>Subject: RE: [EFM-P2MP] FW: [EFM] EFM FEC Proposals
>>
>>
>>Hi Ajay,
>>I have attached a few slides with some remarks regarding the
>>Stream-FEC.
>>
>>
>>Best Regards,
>>Lior
>>
>>
>>
>>
>>-----Original Message-----
>>From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
>>[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org]On Behalf Of Ajay
>>Gummalla
>>Sent: Tuesday, July 02, 2002 8:43 PM
>>To: Larry Rennie; stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx
>>Cc: stds-802-3-efm@xxxxxxxxxxxxxxxxxx
>>Subject: [EFM-P2MP] FW: [EFM] EFM FEC Proposals
>>
>>
>>Larry and all:
>> I have attached a slide which compares the two proposals.
>>I am hoping that this will generate more discussions and help us make
>>progress.
>>
>>Please take a look at
>>http://www.ieee802.org/3/efm/public/jul02/p2mp/gummalla_p2mp_1_0702.pd
f
>>for the calculations on efficiency.
>>
>>Best Regards,
>>Ajay
>>
>>>-----Original Message-----
>>>From: owner-stds-802-3-efm@majordomo.ieee.org
>>>[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of larry
>>>rennie
>>>Sent: Monday, July 01, 2002 6:31 PM
>>>To: stds-802-3-efm
>>>Subject: [EFM] EFM FEC Proposals
>>>
>>>
>>>
>>>Fellow EFM Task Force Members,
>>>
>>>At the last EFM meeting in Edinburgh we passed the following FEC
>>>motion:
>>>
>>>17. Motion to add an FEC option for the 1Gig P2P and P2MP PHY,
>>>maintaining backward compatibility with the 1000BASE-X PCS, for the
>>>following reasons:
>>> 1. Improves reach of a MPN limited link by 50% for links with MPN
>>>penalty of about 2dB
>>> 2. Permits operation at a SNR lower by 2.5 dB for non-dispersion
>>>limited links.
>>>
>>>Two different FEC implementation proposals will be presented in
>>>Vancouver and they are posted under the General Session material on
>>>the EFM web site. One proposal is frame based and the other is
stream
>>>
>>>based. If you are at all interested in FEC for EFM, I encourage you
>>>to please take a look at these two proposals and get your comments
and
>>>
>>>questions back onto the reflector before the meeting. This will give
>>>the presenters and their supporters time to formulate a proper
>>>response and will conserve our precious meeting time in Vancouver.
>>>
>>>Regards,
>>>
>>>Larry
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>