Re: [10GBT] Updated Tables
Seki,
Possibly. The waterfall phenomenon in LDPC codes is still a subject of
research in academic circles.
Regards,
Sailesh Rao.
srao@phyten.com
>From: k.seki@NECEL.COM
>Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] Updated Tables
>Date: Wed, 21 Jul 2004 17:36:27 +0900
>
>Sailesh,
>
>Let me say again that I suggest to compare PAMs with the same "coding
>gain", NOT "gap to Shannon capacity".
>You may get confused coding gain with gap to capacity.
>
>In order to symplify the analysis, let me assume RS(255,239) code as an
>example.
>This RS code can reduce BER from 2E-4 to 1E-12.
>Below are required SNRs and coding gain on PAM8 and PAM12 mapping:
>
> Required SNR for 2E-4 Required SNR for 1E-12 coding gain
>PAM8 24.6dB 30.3dB 30.3-24.6=5.7dB
>PAM12 28.1dB 33.8dB 33.8-28.1=5.7dB
>
>This result show RS(255,239) has the same coding gain on PAM8 and PAM12.
>Do you think this facts change in LDPC codes?
>
>Regards,
>Seki
>
>-----Original Message-----
>From: sailesh rao(sailesh rao <sailesh_rao@HOTMAIL.COM>)
>Sent: Tue, 20 Jul 2004 20:53:26 -0400
><BAY8-F21JPIDPCpCxX500004b7b@hotmail.com>
>Subject: Re: [10GBT] Updated Tables
>Hi Seki,
>
>I've pointed out a technical reason why there could be a 0.5dB loss in the
>LDPC coding gain for the PAM12 proposal. In contrast to the PAM12 approach,
>the PAM8 approach uses every available information bit in the modulation
>levels, and therefore does not suffer from this inefficiency.
>
>If you still wish to assign equal coding gains for PAM8 and PAM12, do you
>have a technical reason for why we should discount this 0.5dB difference
>for
>PAM12? All our simulations to date are showing that there is such a 0.5dB
>difference in coding gains between PAM8 and PAM12...
>
>Regards,
>Sailesh Rao.
>srao@phyten.com
>
> >From: "K. Seki" <k_seki@MTC.BIGLOBE.NE.JP>
> >Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
> >To: STDS-802-3-10GBT@listserv.ieee.org
> >Subject: Re: [10GBT] Updated Tables
> >Date: Tue, 20 Jul 2004 23:59:34 +0900
> >
> >Sailesh,
> >
> >I don't suggest to compare between PAM12 and PAM8 with the same "gap to
> >Shannon capacity".
> >I suggest to compare PAMs with the same "coding gain".
> >Please don't confuse "coding gain" with "gap to Shannon capacity".
> >
> >Regards,
> >Seki
> >
> >-----Original Message-----
> >From: sailesh rao <sailesh_rao@HOTMAIL.COM>
> >Sent: Tue, 20 Jul 2004 09:16:57 -0400
> >Subject: Re: [10GBT] Updated Tables
> >Hi All,
> >
> >PAM12 can code log2(12)=3.585 bits in each symbol. According to Shannon's
> >formula, we need an SNR of
> >
> >10*log10(2^(3.585*2)-1) dB = 21.5536dB
> >
> >to achieve error free operation. However, the proposed PAM12 approach
>only
> >uses 3.5 bits of the 3.585 bits available in the constellation. The
>Shannon
> >limit for 3.5 bits is
> >
> >10*log10(2^(3.5*2)-1) dB = 21.038dB
> >
> >And, the missing 0.5dB reveals itself!!
> >
> >Therefore, please don't arbitrarily penalize the PAM8 system to
>compensate
> >for the inefficiencies in the PAM12 encoding.
> >
> >Thanks,
> >Sailesh Rao.
> >srao@phyten.com
> >
> > >From: k.seki@NECEL.COM
> > >Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
> > >To: STDS-802-3-10GBT@listserv.ieee.org
> > >Subject: Re: [10GBT] Updated Tables
> > >Date: Tue, 20 Jul 2004 21:20:12 +0900
> > >
> > >Hi all,
> > >
> > >I quite agree with Vivek and Jose.
> > >We should compare between PAM12 and PAM8 with the same coding gain.
> > >
> > >Regarding LDPC(833,1024) performance, the average number of error bits
> >per
> > >error events is 24.0.
> > >We have observerd no error in 2.3E-13 bits.
> > >If we would get a single events with 24.0 bits error, BER becomes
>1E-12.
> > >
> > >Anyway, if we can't reach agreement of baseline code,
> > >I would suggest we use a temporary code which has 10dB coding gain.
> > >In this case, the PAM-8 and PAM-12 required SNR for 1E-12 BER become
> > >20.3dB and 23.8dB, respectively.
> > >
> > >Regards,
> > >Seki
> > >NEC Electronics
> > >k.seki@necel.com
> > >
> > >-----Original Message-----
> > >From: sailesh rao(sailesh rao <sailesh_rao@HOTMAIL.COM>)
> > >Sent: Tue, 20 Jul 2004 07:03:48 -0400
> > ><BAY8-F91A7xNmyavTq00004f3cb@hotmail.com>
> > >Subject: Re: [10GBT] Updated Tables
> > >
> > >Vivek,
> > >
> > >In that case, you need to penalize 0.5dB for the PAM12 proposal as
>well.
> >I
> > >don't consider the 1E13 bit simulation to be indicative of a 1E-12 BER.
> > >I've
> > >seen how error events can occur in LDPC simulations - you have 1E13
>bits
> > >simulated with 0 errors and splat, you get a single frame with 60bits
>in
> > >error, thus pushing the BER down to 6E-12. Therefore, until there are
>at
> > >least 20 frame errors counted in a BER estimate, I'm skeptical of the
> > >estimate.
> > >
> > >Or, leave the PAM8 SNR requirement at 19.9dB.
> > >
> > >Sailesh.
> > >
> > > >From: Vivek Telang <vivek@VITESSE.COM>
> > > >Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
> > > >To: STDS-802-3-10GBT@listserv.ieee.org
> > > >Subject: Re: [10GBT] Updated Tables
> > > >Date: Mon, 19 Jul 2004 21:07:31 -0500
> > > >
> > > >Sailesh,
> > > >
> > > >OK, for the sake of my simulations, I am going to assume your
> >worst-case
> > > >required SNR (from your earlier email) of 20.4dB, but ..., I'll hold
> >the
> > > >extra 0.5dB in "escrow", returnable in full to you, when either your
> >sims
> > > >or Amir Mezer's sims prove that the BER=1e-12 can in fact be achieved
> >at
> > > >19.9dB.
> > > >Come on now, that's fair.
> > > >
> > > >Vivek
> > > >
> > > >-----Original Message-----
> > > >From: stds-802-3-10gbt@ieee.org [mailto:stds-802-3-10gbt@ieee.org]On
> > > >Behalf Of sailesh rao
> > > >Sent: Monday, July 19, 2004 8:36 PM
> > > >To: STDS-802-3-10GBT@listserv.ieee.org
> > > >Subject: Re: [10GBT] Updated Tables
> > > >
> > > >
> > > >Vivek,
> > > >
> > > >I disagree. The 1E-12 BER point for the PAM8 proposal is at 19.9dB
>and
> >it
> > > >should stay that way.
> > > >
> > > >The proposed PAM12 approach is fundamentally flawed in its use of SNR
> >vs.
> > > >BER. If you compute the formula,
> > > >
> > > >Fs = 10000/(4*log2(4N) -2)
> > > >
> > > >for N=3, you will find that PAM12 should be running at 810MHz instead
> >of
> > > >the
> > > >supposedly "optimized" 825MHz. If you plug in N=2 in the above
> >formula,
> > > >you
> > > >will find that Fs is 1000MHz, which is as it is proposed for the
>PAM8
> > > >approach.
> > > >
> > > >Please don't compensate the SNR for our PAM8 proposal for the
> > >inadequacies
> > > >of the supposedly "optimized" encoding schemes used in the PAM12
> > >proposal.
> > > >
> > > >Please don't even think about it.
> > > >
> > > >Regards,
> > > >Sailesh Rao.
> > > >srao@phyten.com
> > > >
> > > > >From: Vivek Telang <vivek@VITESSE.COM>
> > > > >Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
> > > > >To: STDS-802-3-10GBT@listserv.ieee.org
> > > > >Subject: Re: [10GBT] Updated Tables
> > > > >Date: Mon, 19 Jul 2004 19:58:44 -0500
> > > > >
> > > > >Sailesh,
> > > > >
> > > > >In that case, to simplify comparisons, I propose that we decouple
>the
> > > >line
> > > > >code variable from the analysis, and assume the same coding gain
>for
> > >both
> > > > >line codes.
> > > > >I believe the coding gain assumed in Scott's presentation was 10.0
>dB
> > > > >(33.8-23.8), so shall we say that the PAM-8 SNR required for
> >BER=1e-12
> > >is
> > > > >30.3-10 = 20.3 dB?
> > > > >
> > > > >Vivek
> > > > >
> > > > >-----Original Message-----
> > > > >From: stds-802-3-10gbt@ieee.org
>[mailto:stds-802-3-10gbt@ieee.org]On
> > > > >Behalf Of sailesh rao
> > > > >Sent: Monday, July 19, 2004 6:11 PM
> > > > >To: STDS-802-3-10GBT@listserv.ieee.org
> > > > >Subject: Re: [10GBT] Updated Tables
> > > > >
> > > > >
> > > > >Vivek,
> > > > >
> > > > >Thanks for the opportunity.
> > > > >
> > > > >At the meeting, Jose pointed out that the extension of the SNR/BER
> > >curve
> > > >I
> > > > >made on the (2048,1723) code from 6E-11 BER down to 1E-12 BER
>(slide
> >10
> > > >of
> > > > >rao_1_0704.pdf) was not based on real simulations. I had assumed
>that
> > >the
> > > > >1E-12 BER assertions on slide 4 of seki_1_0304.pdf was based on
>real
> > > > >simulations, but it was apparently just a "hand extrapolation" of
>my
> > > > >original SNR/BER curve. Unfortunately, this point was not
>clarified
> >to
> > > >me
> > > > >during my e-mail correspondence with Dr. Seki.
> > > > >
> > > > >At the moment, I stand by the 6E-11 BER point in the BER vs. SNR
> >curve
> > >of
> > > > >the (2048,1723) LDPC code since I personally supervised the
> >generation
> > >of
> > > > >this simulation point. In the worst-case, assuming Murphy's law
> > >applies,
> > > >we
> > > > >can expect the BER/SNR curve for the (2048,1723) LDPC code to
> >undertake
> > >a
> > > > >slope change in parallel with the uncoded Gaussian curve and the
> > > >intercept
> > > > >for the 1E-12 BER will occur slightly higher than 19.9dB (my
> > > >extrapolation
> > > > >shows 20.4dB, not 20.9dB).
> > > > >
> > > > >However, this is a moot point. If Amir Mezer's LDPC simulations
>show
> > >that
> > > > >the (2048,1723) LDPC code has a slope change at 6e-11 BER, I will
> > > >instantly
> > > > >recommend adding a row to the Djurdjevic construction for the
> > >(2048,1723)
> > > > >code and pushing the slope change down below the 1E-12 BER point.
>Or,
> > >for
> > > > >that matter, if Amir Mezer's simulations show that the (992,829)
>LDPC
> > > >code
> > > > >has no slope change until 1E-12 BER, I will recommend we switch to
> >that
> > > > >code. I am aware that Amir Mezer has close to infinite computing
> > > >resources
> > > > >since he is employed at Intel (Amir, I hope things haven't
> >changed!!!),
> > > >and
> > > > >therefore, we can rely on him to validate the specific LDPC code
>the
> > >task
> > > > >force is using down to 1E-12 BER and beyond.
> > > > >
> > > > >The bottom line is that the PAM8 modulation scheme is not wedded to
>a
> > > > >specific Djurdjevic LDPC code and we should really dis-associate
>the
> > > > >specific LDPC code choice from the choice of PAM levels. For
> >instance,
> > > >the
> > > > >PAM8 proposal will work just fine with the (1024,833) code the
>PAM12
> > > > >proponents are using, though I would personally hesitate to add
>such
> >a
> > > > >SONET-on-Steroids like framing complexity in an Ethernet standard.
> > >Heck,
> > > >we
> > > > >had interoperablilty problems with the scrambler definition on
> > >1000BASE-T
> > > >-
> > > > >do we really want to deal with interoperability issues with such a
> > > >complex
> > > > >framing scheme in 10GBASE-T?
> > > > >
> > > > >Regards,
> > > > >Sailesh Rao.
> > > > >srao@phyten.com
> > > > >
> > > > > >From: Vivek Telang <vivek@VITESSE.COM>
> > > > > >Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
> > > > > >To: STDS-802-3-10GBT@listserv.ieee.org
> > > > > >Subject: Re: [10GBT] Updated Tables
> > > > > >Date: Mon, 19 Jul 2004 16:17:39 -0500
> > > > > >
> > > > > >Hi Sailesh,
> > > > > >
> > > > > >At the meeting last week, there was a question raised (by Jose)
> >about
> > > >the
> > > > > >PAM-8 SNR requirement of 19.9 dB for BER=1e-12 (column 3 of your
> > > >table).
> > > > >I
> > > > > >think he said that it was actually ~1dB worse than that
>(~20.9dB),
> > >but
> > > > >I'm
> > > > > >not positive. There was a discussion, but I don't think the
>matter
> > >got
> > > > > >resolved, so can you clarify?
> > > > > >
> > > > > >Thanks,
> > > > > >
> > > > > >Vivek
> > > > > >
> > > > > >-----Original Message-----
> > > > > >From: stds-802-3-10gbt@ieee.org
> >[mailto:stds-802-3-10gbt@ieee.org]On
> > > > > >Behalf Of sailesh rao
> > > > > >Sent: Monday, July 19, 2004 2:02 PM
> > > > > >To: STDS-802-3-10GBT@listserv.ieee.org
> > > > > >Subject: [10GBT] Updated Tables
> > > > > >
> > > > > >
> > > > > >10GBT'ers:
> > > > > >
> > > > > >In the attached, I've updated the 3 tables in our July
>presentation
> > > >based
> > > > > >on
> > > > > >the following:
> > > > > >
> > > > > >1. Change PAM12 symbol rate to 825Ms/s from 820Ms/s.
> > > > > >2. Delete PAM10 entry.
> > > > > >3. As Luc pointed out, add a 1.2dB emissions penalty for PAM12
>due
> >to
> > > >its
> > > > > >higher transmit PSD.
> > > > > >4. As Jose pointed out, subtract 0.4dB from the PAM12 emissions
> > >penalty
> > > > >due
> > > > > >to the THP peak voltage adjustment.
> > > > > >
> > > > > >Next, I integrated the WGN for 1E-12 BER over the Nyquist
>frequency
> > > >range
> > > > > >to
> > > > > >get a "wideband noise tolerance" measure for the two proposals.
> > > >Finally,
> > > > >I
> > > > > >summed the noise immunity penalty and the emissions penalty for
>the
> > > >PAM12
> > > > > >proposal to form a "Total EMI Penalty" metric over the PAM8
> >approach.
> > > > > >
> > > > > >In Models 1 and 3, the penalty works out to be 2.6dB and 2.2dB
> > > > >respectively
> > > > > >for PAM12 over PAM8. However, in Model 2, which represents the
> > >existing
> > > > > >cabling infrastructure, the penalty for PAM12 over PAM8 works out
> >to
> > >a
> > > > > >whopping 4.0dB!!
> > > > > >
> > > > > >Regards,
> > > > > >Sailesh Rao.
> > > > > >srao@phyten.com
> > > > > >
> > > > > >_________________________________________________________________
> > > > > >MSN Toolbar provides one-click access to Hotmail from any Web
>page
> >-
> > > >FREE
> > > > > >download!
> > >http://toolbar.msn.click-url.com/go/onm00200413ave/direct/01/
> > > > >
> > > > >_________________________________________________________________
> > > > >Planning a family vacation? Check out the MSN Family Travel guide!
> > > > >http://dollar.msn.com
> > > >
> > > >_________________________________________________________________
> > > >Is your PC infected? Get a FREE online computer virus scan from
>McAfee
> > >$B%g (B
> > > >Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >
> >_________________________________________________________________
> >Discover the best of the best at MSN Luxury Living. http://lexus.msn.com/
>
>_________________________________________________________________
>Don $BCU (B just search. Find. Check out the new MSN Search!
>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/