Re: [8023-10GEPON] [FEC Superating] - kickoff preso
Mike-
My recollection for the reason for 64/66 coding was its very low
overhead/high coding efficiency (96+%) as opposed to 8B/10B (80%) therby
lowering the optical bandwidth requirements at a time when we were
stretching things
Geoff
At 08:04 AM 2/9/2007 , Mike Dudek wrote:
>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.
> >> >
> >