Re: [10GBT] Updated Tables
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/
----------------------------------------
$B4X!!9nIR (B(Katsutoshi $B!! (BSEKI)
NEC $B%(%l%/%H%m%K%/%9DL?.%7%9%F%`;v6HIt (B
e-mail k.seki@necel.com
$B<RFb (BMAIL 22-25371
TEL 044-435-1625(8-22-27070)
FAX 044-435-1932(8-22-25315)