Re: [8023-10GEPON] [FEC Superating] - kickoff preso
Mike:
Another reason for 64/66 is delimiter robustness. An important criteria
for system implementers is the probability of undetected error (the
target has traditionally been less than one in 20 years). Scrambling on
its own does not provide great robustness in delimiting a frame. If a
new code or scrambling is used, I for one will want to see an undetected
error analysis that demonstrates acceptable undetected error rates.
--Bob
-----Original Message-----
From: Mike Dudek [mailto:mike.dudek@PICOLIGHT.COM]
Sent: Friday, February 09, 2007 9:47 AM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
Geoff
I agree that low overhead was why 64B/66B was chosen versus 8B/10B.
However I was trying to question why there was any coding (besides
scrambling)at all. I think the reason for 10GBE was so that frame
alignment can be easily achieved. In the EPON upstream I think there
is already a proposal for a strong alignment mechanism for burst
synchonization and I would have thought that this could be used for
frame alignment as well, thereby removing the need for 64/66 coding and
hence reducing the line rate. (This incidentally would change the need
for special characters from being 66bits long to being 64bits long,
(assuming that the 64 bits block length is used. Note my
understanding is that a significant fraction of Ethernet frames are
64bits long, so although having removed 64/66bit encoding would allow a
choice of a different "block length" altogether I wouldn't recommend
it).
Mike.
-----Original Message-----
From: Geoff Thompson [mailto:gthompso@nortel.com]
Sent: Friday, February 09, 2007 10:30 AM
To: Mike Dudek
Cc: STDS-802-3-10GEPON@listserv.ieee.org
Subject: 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.
> >> >
> >