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.
>