Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-10GEPON] [FEC Superating] - kickoff preso



Eric

RE:
>- PMD is a serial interface that runs at 10.3125 GBd

PMD is not an interface. PMD stands for "Physical Media Dependent" It is a 
generic sub-layer of the Physical Layer of our adaptation of the 7 Layer 
model. It first came into use in 802.3 when we did 100 Mb/s and plagiarized 
material from FDDI. Thus, contrary to your statement:
         It is not (necessarily) serial
         It is not an interface
         It does not (necessarily) run at 10.3125 GBd
Therefore your follow-on terminology is not correct nor consistent with 
existing 802.3 terminology.

Geoff Thompson

At 03:26 PM 1/31/2007 , Eric Lynskey wrote:
>Frank,
>
>To start with, thanks for putting these slides together.  It's a very good
>start to getting the discussion going.
>
>Here is a list of the defined interfaces in the existing 802.3ae standard:
>
>- XGMII is a 32-bit wide interface that runs at 156.25 MHz * 2
>- XAUI is a 10-bit wide interface that runs at 3.125 GBd
>- XSBI is a 16-bit wide interface that runs at 644.53125 MHz
>- PMD is a serial interface that runs at 10.3125 GBd
>
>For the FEC with a higher line-rate, we could have something like this:
>
>- FEC/PMD is a serial interface that could run at 11.049 GBd
>
>The increase in baud rate is needed to account for the added parity bytes.
>If we go with the higher line rate, will we need a buffer to add/delete
>idles in order to adapt between the different line speeds?
>
>I recognize that there is an existing mechanism mentioned in Clause 49 that
>can help with this (49.2.5 for Transmit, 49.2.11 for Receive).  I think that
>with either the line-rate or MAC-rate modification there will still need to
>be additional idle insertion/deletion within the PHY.  In one case we are
>adding idles to decrease the data rate to account for the parity insertion,
>and in the other case we are adding idles to adapt between clock boundaries
>and/or rates.
>
>If we choose to go with a line-rate modification, than we are probably going
>to be forced to go with an existing rate.  I haven't heard anyone propose
>that we use a line rate not currently used by any other applications.  If
>that is the case, then would that restrict us to the exact FEC algorithms
>already being used at those higher rates?  There may be more flexibility in
>selecting an FEC algorithm if we stick to the 10.3125 rate.
>
> From yesterday's ad-hoc call, it looks like we may be going with a 29dB
>channel loss and up to 3dB in additional penalties, for a 30dB-32dB power
>budget, so we need to keep that in mind, too.
>
>- Eric Lynskey
>
>
>-----Original Message-----
>From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
>Sent: Wednesday, January 31, 2007 12: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.