Re: [8023-10GEPON] [FEC Superating] - kickoff preso
Returning to Thomas Schrans original point. My understanding (I'm not
an expert on this) is that the 64/66 coding was included in 10GBE to be
able to easily find alignment. Although it does guarantee one
transition every 66 bits that is not an important property for the
optical transceivers as statistically there is much more timing content
for clock extract in the scrambled data. I don't think there was any
other reasons for including it. If I've followed the threads
correctly, on the upstream path there is already going to be a very good
pattern included to provide the Synchronizing function (at the beginning
of the burst) so I see no need to have the 64/66 in this direction.
-----Original Message-----
From: Raymond Leung [mailto:wkleung@HUAWEI.COM]
Sent: Friday, February 09, 2007 4:49 AM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: 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.
>> >
>