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