Re: [8023-10GEPON] [FEC Superating] - kickoff preso
Dear Glen
> 1) Are non-systematic codes more efficient? In other words, is overhead
> of non-systematic codes different (lower) compared to the overhead added
> by a systematic code for the same gain?
In the coding theory point of view, code gain related to code rate (lower
the rate, higher the gain); code length (longer the length, higher the
gain); and decoding algorithm (soft algorithm typical perform 1~3dB better
than hard algorithm does). Systematic or not is not the case.
> 2) Are there non-systematic codes that make encoded data sufficiently
> DC-balanced? If yes, it could be that scrambler would become
> unnecessary.
In order to achieve DC-balanced, the code should have balance (or near
balance) number of bit 1s and bit 0s in all (or majority) of its codewords.
As far as I know, there are some of such systematic codes which have balance
number of 1s and 0s in all of its codeword except the all-zero codeword.
However, most of them are low rate code, e.g. Hadamard code.
Regards,
Raymond
----- Original Message -----
From: "Glen Kramer" <glen.kramer@TEKNOVUS.COM>
To: <STDS-802-3-10GEPON@listserv.ieee.org>
Sent: Friday, February 09, 2007 3:47 AM
Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
> Thomas,
>
>
> The FEC code used in 1G EPON was *systematic*, meaning that it leaves
> data symbols unchanged, and adds parity as a separate block. This was
> important to allow non-FEC devices to be able to receive FEC-coded data.
>
> But if we are talking about FEC being mandatory, perhaps we should look
> at non-systematic codes.
>
> Effectively, 10G scrambling used together with systematic FEC already
> makes it a non-systematic code. And I am wondering if these functions
> are more efficient when combined.
>
> Could anyone answer these questions:
>
> 1) Are non-systematic codes more efficient? In other words, is overhead
> of non-systematic codes different (lower) compared to the overhead added
> by a systematic code for the same gain?
>
> 2) Are there non-systematic codes that make encoded data sufficiently
> DC-balanced? If yes, it could be that scrambler would become
> unnecessary.
>
>> I just know that my 10Gb/s transceiver and optics
>> have to work at 10.3125Gb/s, and now maybe 11.04Gb/s with FEC.
>
> There are two options on the table. Either keep the data rate as it is
> without FEC and increase outgoing line rate (PHY super-rating), or slow
> down the incoming data, and keep line rate as it is now - 10.3125 Gb/s
> (MAC sub-rating).
>
> You need to tell us what impact going to from 10.3125 to ~11.05 Gb/s
> will have on you, from the point of view of manufacturability, yield,
> testing, operational stability, etc.
>
>
> Glen
>
> ------------------------------------------------------------------------
> --
> DISCLAIMER: This e-mail expresses my views as an individual contributor
> to
> the task force, not as task force chair.
> ------------------------------------------------------------------------
> --
>
>
>
>> -----Original Message-----
>> From: Thomas Schrans [mailto:TSchrans@OCP-INC.COM]
>> Sent: Thursday, February 08, 2007 10:41 AM
>> To: STDS-802-3-10GEPON@listserv.ieee.org
>> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>>
>> Jeff,
>>
>> Not knowing how to do the PCS and the FEC, I can not tell you if this
> is
>> what I mean.
>>
>> All I am trying to ask is the following
>>
>> We start with 10Gb/s
>> We add 3.125% overhead for PCS 64B/66B, to get to 10.3125Gb/s
>> We add say 7% overhead for FEC, to get to ~11.04Gb/s.
>>
>> By increasing the optical line rate, we start squeezing the optical
>> specs and their cost.
>>
>> Wouldn't it be nice if the purpose of the PCS could be combined into
> the
>> FEC, resulting in a reduced overhead?
>>
>> From a transceiver point of view, I don't know what the purpose of the
>> 64B/66B coding is. I just know that my 10Gb/s transceiver and optics
>> have to work at 10.3125Gb/s, and now maybe 11.04Gb/s with FEC.
>>
>> Hopefully some of the PCS and FEC experts on the reflector can answer
>> this, even if the answer is "Thomas you're out of your mind. Those 2
>> functions can not be combined because ..."
>>
>> Regards,
>>
>> Thomas
>>
>>
>> -----Original Message-----
>> From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
>> Sent: Thursday, February 08, 2007 10:01 AM
>> To: STDS-802-3-10GEPON@listserv.ieee.org
>> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>>
>> Thomas,
>>
>> If you mean "why not use 1 bit of the PCS header for FEC parity and
>> scramble the other bit like they did in 802.3ap - and then we need
> only
>> 100 (== 128 - 28) additional bits of parity per FEC codeword?" ...
>>
>> ... then the answer would seem to be that you could in fact do that,
> but
>> that the resulting numbers are not any easier to work with. In
>> particular if we want to put the parity data into a 66b block (as we
>> have been assuming) there is no advantage because 2 66b blocks are
>> still needed.
>>
>>
>> -----Original Message-----
>> From: Thomas Schrans [mailto:TSchrans@OCP-INC.COM]
>> Sent: Thursday, February 08, 2007 7:41 PM
>> To: STDS-802-3-10GEPON@listserv.ieee.org
>> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>>
>> I'm neither a FEC expert nor a PCS expert, so I have what may look
> like
>> a simple question:
>>
>> Why can we not combine the PCS overhead (64B/66B =3%) and FEC overhead
>> (~7%), so that the combined overhead is less than the sum of the two.
>>
>> Regards,
>>
>> Thomas Schrans, Ph.D.
>> Design Engineering Manager
>> Optical Communication Products, Inc.
>>
>> -----Original Message-----
>> From: EffenbergerFrank 73695 [mailto:feffenberger@HUAWEI.COM]
>> Sent: Wednesday, February 07, 2007 11:35 PM
>> To: STDS-802-3-10GEPON@listserv.ieee.org
>> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>>
>> The actual rate is the repeating fraction. But, it is not a problem
> to
>> have a rate that is not expressible in a short fraction. However, a
>> round number has a 'prettiness factor.'
>>
>> What is important that the rates have a reasonably simple ratio.
>>
>> Frank E.
>>
>>
>>
>>
>> ----- Original Message -----
>> From: glen kramer <glen.kramer@TEKNOVUS.COM>
>> Date: Tuesday, February 6, 2007 5:16 pm
>> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>>
>> > Frank,
>> >
>> > > Just as a for-example, the 11.049 GHz happens to be 15/14ths of
>> > 10.3125.
>> >
>> > I calculate that 15/14ths of 10.3125 is equal
>> > 11.049107142857142857142857142857...
>> >
>> > Is this a problem? Should super-rating employ additional rate
>> > adaptationmechanism to make it a "nice" number?
>> >
>> > For example, inserting one extra block every 1875 blocks will bring
>> > the rate up to 11.055.
>> >
>> >
>> > Glen
>> >
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: Jeff Mandin [Jeff_Mandin@PMC-SIERRA.COM]
>> > > Sent: Tuesday, February 06, 2007 1:41 AM
>> > > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
>> > > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>> > >
>> > > Frank,
>> > >
>> > > I think you might be conflating the loop timing issue with some
>> > other> issue raised earlier.
>> > >
>> > > The point I intended to raise about loop timing is that the
> upstream
>>
>> > > frequency of 1.25 GHz is fixed already, and in the asymmetric 10/1
>> > case
>> > > the ONU needs to derive the upstream clock from the downstream
>> > signal.Of
>> > > course how easy or difficult it is to do that depends both on the
>> > > dividability of the downstream frequency by 1.25 Ghz and also
>> > on the
>> > > jitter of the downstream signal.
>> > >
>> > > 11.25 Ghz (rather than 11.049 GHz) would be fine. Can XFI/SPI
>> > components
>> > > go that fast?
>> > >
>> > > - Jeff
>> > >
>> > > -----Original Message-----
>> > > From: Frank Effenberger [feffenberger@HUAWEI.COM]
>> > > Sent: Monday, February 05, 2007 6:02 PM
>> > > To: STDS-802-3-10GEPON@listserv.ieee.org
>> > > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>> > >
>> > > All,
>> > >
>> > > I don't think that clock management is so strong an advantage
>> > for one
>> > > scheme over the other. In all the cases, in all the technologies,
>> > there
>> > > are a set of frequencies that are phase-locked to each other.
>> > Dividers
>> > > and PLLs do a fine job of inter-converting them. One is not much
>> > harder
>> > > than the other, unless we choose a poor frequency for the
>> > super-rating.
>> > > We should be more careful!
>> > >
>> > > Just as a for-example, the 11.049 GHz happens to be 15/14ths of
>> > 10.3125.
>> > > Those are reasonably small clock dividers, and not a big problem
> to
>> > > implement. Note that this division builds on top of the 33/32nds
>> > clock
>> > > ratio of 64b66b. If we go with super-rating, then I see no
>> > reason to
>> > > maintain the redundant framing bit. Rather, I think we would
>> > look for
>> > a
>> > > clock relationship from the FEC super-rate directly to the 10G
> base
>> > rate.
>> > >
>> > > In any case, I will add the item to the list, for completeness
> sake.
>> > >
>> > > Regards,
>> > > Frank E.
>> > >
>> > >
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Jeff Mandin [Jeff_Mandin@PMC-SIERRA.COM]
>> > > Sent: Monday, February 05, 2007 9:19 AM
>> > > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
>> > > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>> > >
>> > > Frank hi,
>> > >
>> > > Loop-timing for the asymmetric 10/1 case would appear to be
> another
>> > "pro"
>> > > for the subrating scheme.
>> > >
>> > > The ONU can - perhaps - use the recovered 10.3125 clock to
>> > derive one
>> > of
>> > > 312.5 Mhz (divide by 33), and then use a PLL to generate the
>> > upstreamrate
>> > > (multiply by 4). With 11.1 Gb/s XSBI this would probably be
>> > much more
>> > > difficult.
>> > >
>> > > - Jeff
>> > >
>> > > -----Original Message-----
>> > > From: Frank Effenberger [feffenberger@HUAWEI.COM]
>> > > Sent: Wednesday, January 31, 2007 10:32 PM
>> > > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
>> > > Subject: [8023-10GEPON] [FEC Superating] - kickoff preso
>> > >
>> > > Dear All,
>> > >
>> > > I have put together the following presentation on the issue of
>> > FEC and
>> > > line-rate vs. MAC-rate modification. I tried to include in these
>> > slides
>> > > all the arguments I have heard favoring one method or the other.
>> > If I
>> > > have forgotten your favorite, you can shoot an Email to me, and
> I'll
>> > add
>> > > it to the list.
>> > >
>> > > You may also note that the last slide, entitled "Reaching a
>> > decision"is
>> > > blank. I don't know a truly objective way to solve this
>> > problem... It
>> > > seems to me that when you stack up the pros and cons, these two
>> > schemes
>> > > are pretty equal.
>> > >
>> > > One last thought: The one 'hard' (objective) con for the super-
>> > rating> scheme is the loss of 0.3 dB of sensitivity. The one
>> > 'hard' con for
>> > the
>> > > sub-rating scheme is the loss of bandwidth (7% lost). How can
>> > we put
>> > > these two items
>> > > on a common comparative base? Usually, the common denominator in
>> > these
>> > > situations is cost, so...
>> > > What is the relative system cost increase due to 0.3dB optical
> loss?
>> > > What is the relative system cost increase due to a 7% capacity
> loss?
>> > > If someone wants to hazard an answer to these questions, please
> do.
>> > >
>> > > Regards,
>> > > Frank E.
>> >
>