Re: [10GBT] Updated Tables
Let's discuss the use of Intel computing resources offline rather than
over the reflector.
From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On
Behalf Of sailesh rao
Sent: Tuesday, July 20, 2004 2:11 AM
Subject: Re: [10GBT] Updated Tables
Thanks for the opportunity.
At the meeting, Jose pointed out that the extension of the SNR/BER curve
made on the (2048,1723) code from 6E-11 BER down to 1E-12 BER (slide 10
rao_1_0704.pdf) was not based on real simulations. I had assumed that
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
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
the (2048,1723) LDPC code since I personally supervised the generation
this simulation point. In the worst-case, assuming Murphy's law applies,
can expect the BER/SNR curve for the (2048,1723) LDPC code to undertake
slope change in parallel with the uncoded Gaussian curve and the
for the 1E-12 BER will occur slightly higher than 19.9dB (my
shows 20.4dB, not 20.9dB).
However, this is a moot point. If Amir Mezer's LDPC simulations show
the (2048,1723) LDPC code has a slope change at 6e-11 BER, I will
recommend adding a row to the Djurdjevic construction for the
code and pushing the slope change down below the 1E-12 BER point. Or,
that matter, if Amir Mezer's simulations show that the (992,829) LDPC
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
since he is employed at Intel (Amir, I hope things haven't changed!!!),
therefore, we can rely on him to validate the specific LDPC code the
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,
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,
had interoperablilty problems with the scrambler definition on
do we really want to deal with interoperability issues with such a
framing scheme in 10GBASE-T?
>From: Vivek Telang <vivek@VITESSE.COM>
>Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
>Subject: Re: [10GBT] Updated Tables
>Date: Mon, 19 Jul 2004 16:17:39 -0500
>At the meeting last week, there was a question raised (by Jose) about
>PAM-8 SNR requirement of 19.9 dB for BER=1e-12 (column 3 of your
>think he said that it was actually ~1dB worse than that (~20.9dB), but
>not positive. There was a discussion, but I don't think the matter got
>resolved, so can you clarify?
>From: firstname.lastname@example.org [mailto:email@example.com]On
>Behalf Of sailesh rao
>Sent: Monday, July 19, 2004 2:02 PM
>Subject: [10GBT] Updated Tables
>In the attached, I've updated the 3 tables in our July presentation
>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
>higher transmit PSD.
>4. As Jose pointed out, subtract 0.4dB from the PAM12 emissions penalty
>to the THP peak voltage adjustment.
>Next, I integrated the WGN for 1E-12 BER over the Nyquist frequency
>get a "wideband noise tolerance" measure for the two proposals.
>summed the noise immunity penalty and the emissions penalty for the
>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
>for PAM12 over PAM8. However, in Model 2, which represents the existing
>cabling infrastructure, the penalty for PAM12 over PAM8 works out to a
>MSN Toolbar provides one-click access to Hotmail from any Web page -
Planning a family vacation? Check out the MSN Family Travel guide!