Re: [BP] Additions to Signaling spread sheet
Hi Vivek,
It seems like we are now back to my original concern ...
While we agree that SNR is a pessimistic estimate, how do we establish that
it treats different signaling schemes with the same degree of pessimism?
Brian
p.s. can you be specific on how jitter and timing margins are accounted for?
Do you compute a "horizontal" SNR and then assume it extends as a gaussian?
Once you go to this level in matlab, why not just go a little further and
compute the actual pdf (ala. StatEye)?
> -----Original Message-----
> From: owner-stds-802-3-blade@listserv.ieee.org [mailto:owner-stds-802-3-
> blade@listserv.ieee.org] On Behalf Of Vivek Telang
> Sent: Wednesday, December 01, 2004 2:05 PM
> To: STDS-802-3-BLADE@listserv.ieee.org
> Subject: Re: [BP] Additions to Signaling spread sheet
>
> Hi Brian,
>
> The only reason I added the "(almost)" was to be strictly correct. I can
> think of pathological pdfs for which the SNR based BER is not
> pessimistic. For example, (i) a pdf that is skinny with a long tail, for
> which the rms would be small, but the peak would be large, or (ii) a
> multi-modal pdf. But I have no reason to believe that these pdfs are
> realistic in our environment. So all practical purposes, I believe that
> the SNR based BER will be pessimistic.
>
> I too don't have a favorite in this race, and I am only interested in a
> fair evaluation. I plan to evaluate all the proposals, which is why
> keeping the computational burden low is very important to me.
>
> Jitter and timing margins can be accounted for in the MATLAB analysis
> fairly easily. It has always been included in the analysis that we use
> to evaluate receiver architectures. The random jitter is assumed to have
> a Gaussian pdf.
>
> Hope this helps to answer your questions.
>
> Regards,
>
> Vivek
>
>
>
> -----Original Message-----
> From: owner-stds-802-3-blade@listserv.ieee.org
> [mailto:owner-stds-802-3-blade@listserv.ieee.org] On Behalf Of Brian
> Brunn
> Sent: Wednesday, December 01, 2004 6:38 AM
> To: STDS-802-3-BLADE@listserv.ieee.org
> Subject: Re: [BP] Additions to Signaling spread sheet
>
>
> Hi Vivek,
>
> You make an excellent observation of the potential for a one-sided
> bound. I agree that a BER projection based on SNR will generally be
> pessimistic. Do you have any insight into when the "(almost)" would
> come into play?
>
> I raised my concern as a member of the 802.3ap Task Force where my
> primary objective is to help us collectively reach a good conclusion. I
> don't prefer to see any particular signaling scheme handicapped. At the
> end of the day, I have to build something.
>
> In addition, I was under the impression that groups would continue to
> report results on multiple signaling schemes, thus reinforcing the need
> for equal treatment.
>
> How is jitter and timing margin handled in an SNR to BER projection? Is
> it
> (almost) always anticipated to be pessimistic as well?
>
> Regards,
> Brian
>
>
>
>
> > -----Original Message-----
> > From: owner-stds-802-3-blade@listserv.ieee.org
> > [mailto:owner-stds-802-3- blade@listserv.ieee.org] On Behalf Of Vivek
> > Telang
> > Sent: Tuesday, November 30, 2004 10:11 PM
> > To: STDS-802-3-BLADE@listserv.ieee.org
> > Subject: Re: [BP] Additions to Signaling spread sheet
> >
> > Hi Brian,
> >
> > If I am interpreting your objection correctly, you are saying that the
>
> > non-Gaussian ISI will be more "bounded" than a Gaussian pdf, and hence
>
> > a BER projection based on the SNR will be more pessimistic. In fact it
>
> > is safe to say that a BER projection based on SNR will (almost) always
>
> > be pessimistic.
> >
> > In that case, let me propose a compromise:
> > If you think that your favorite signaling scheme will be better served
>
> > by a BER simulation, then the burden is on you to prove its
> > performance using a BER simulation If you think that the performance
> > of your favorite signaling scheme is reasonably accurately represented
>
> > by its SNR, then you can use SNR to project the BER. If anything, you
> > will be hurting your own scheme.
> >
> > This way the computational burden is placed only on those who choose
> > it.
> >
> > Regards,
> >
> > Vivek
> >
> > ________________________________
> >
> > From: owner-stds-802-3-blade@listserv.ieee.org on behalf of Brian
> > Brunn
> > Sent: Tue 11/30/2004 7:37 PM
> > To: STDS-802-3-BLADE@listserv.ieee.org
> > Subject: Re: [BP] Additions to Signaling spread sheet
> >
> >
> >
> > Hi Vivek,
> >
> > ISI is so non-gaussian that I would be very hesisitant to accept that
> > it treats all signaling techniques equally.
> >
> > Regards,
> > Brian
> >
> >
> >
> > ----- Original Message -----
> > From: "Vivek Telang" <vtelang@broadcom.com>
> > To: <STDS-802-3-BLADE@listserv.ieee.org>
> > Sent: Tuesday, November 30, 2004 7:37 PM
> > Subject: Re: [BP] Additions to Signaling spread sheet
> >
> >
> > Mike, Mary, and all,
> >
> > For the purposes of comparing the signaling proposals, it may be
> > overkill to run long BER simulations. The goal here is to evaluate the
>
> > performance of a signaling scheme and verify that the proposed
> > receiver complexity is adequate to meet the performance requirements.
> > Fortunately, it is quite straightforward to determine the performance
> > of finite-length equalizer receivers, without having to run long BER
> > simulations. Closed form MATLAB analysis can be used to determine the
> > steady state performance of FFE/DFE based systems. This has a long
> > history in many of the DSP-based comm. systems, including 1000BASE-T
> > and now 10GBASE-T. Historically, the steps in determining feasibility
> > have been (1) Channel Capacity (ideal) (2) Salz Bound (more realistic)
>
> > (3) Finite length MMSE analysis (much more realistic, except for
> > transient
> > behavior) and (4) Finite length, finite precision simulations (the
> real
> > deal). While these steps are in the order of approaching real-life
> > behavior, they also involve increasing computational resources. In
> > particular, the jump from step 3 to step 4 is huge. I am suggesting
> that
> > we use step 3 for the purpose of evaluating the signaling proposals.
> >
> > There are obvious shortcomings to this method, and I'll be the first
> > to list them: 1. Transient behavior (e.g., adaptation) is not modeled
> > 2. Finite precision effects are not modeled
> > 3. The performance evaluation is based on SNR and not BER (so there is
> > an implicit Gaussian assumption for the noise)
> >
> > But IMHO, the computational simplicity outweighs the flaws. Note, I am
>
> > proposing this only for the purpose of solving the problem in front of
>
> > us, which is to pick one signaling proposal. I would contend that the
> > shortcomings do not offer an advantage to one proposal or another.
> >
> > Regards,
> >
> > Vivek
> >
> > Vivek Telang
> > Broadcom Corp.
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-3-blade@listserv.ieee.org
> > [mailto:owner-stds-802-3-blade@listserv.ieee.org] On Behalf Of
> > Altmann, Michael W
> > Sent: Tuesday, November 30, 2004 4:34 PM
> > To: STDS-802-3-BLADE@listserv.ieee.org
> > Subject: Re: [BP] Additions to Signaling spread sheet
> >
> >
> > Mary,
> >
> > Thanks for your input. I will try to capture this for our discussion
> > on Friday.
> >
> > I am concerned about the simulation load for all the data patterns.
> > In general, longer patterns are tougher than short patterns, but they
> > take longer to simulate because of the data pattern probabilities.
> > This causes a problem because, in the strictest terms, a PRBS pattern
> > requires a simulation of 2^n-1 bits to extract all combinations of
> > data to find the inside (w/c) eyelids, and/or the transition
> > probability densities (if BER is to be calculated that way). For
> > PRBS(31), this is a 4Gbit (about 0.4seconds) simulation.
> >
> > While it is posible that we may need to do some long sims for final
> > fine-tuning of things, this is about 4 orders of magnitude more than I
>
> > have CPU for. Do you see a way that we can shorten these sims for the
>
> > purposes of evaluating the basic signaling comparisons?
> >
> > .../Mike
> >
> > -----Original Message-----
> > From: Mary Mandich [mailto:mandich@lucent.com]
> > Sent: Tuesday, November 30, 2004 1:43 PM
> > To: Altmann, Michael W; STDS-802-3-BLADE@listserv.ieee.org
> > Subject: Additions to Signaling spread sheet
> >
> > Hi:
> >
> > Here are our suggestions for input to the Signaling spreadsheet
> > V3.2:
> >
> > 1) On the coding summary worksheet:
> >
> > Split rows for Power (32-34) into additional entries as follows (all
> > under power subheading):
> >
> > Power (typical) Total, Tx, Rx, other (backchannel, FEC, extra clocks,
> > etc.)
> > Power (best) Total, Tx, Rx, other (backchannel, FEC, extra clocks,
> > etc.)
> > Power (worst) Total, Tx, Rx, other (backchannel, FEC, extra clocks,
> > etc.)
> >
> > A note should be added that best/worst/typical refers to powers
> > required for all of the channels on the V&T worksheet.
> >
> > 2) On the V&T worksheet:
> >
> > Need to specify data patterns that must be exercised in reporting the
> > BER and report the worst case. I suggest we choose the following BER
> > patterns for simulations:
> >
> > - PRBS 7 or 9
> > - PRBS 15 -- or the longest the group believes is reasonable for
> > simulations
> >
> > Also, if it is expected that actual measurement data will be reported,
>
> > should specify that BER be reported for
> >
> > - PRBS 17
> > - PRBS 23
> > - PRBS 31
> > - a CID (consecutive identical digit) pattern containing one string
> > each of zeros
> > and ones with have zero timing content separated by a PRBS31
> > pattern.
> > The length of this string is given by the worst case longest
> > such sequence
> > in data, autonegotiation, etc. sequences.
> >
> > Regards,
> >
> > Mary
> >
> > __________________________________________
> >
> > Mary Mandich
> > Technical Manager
> > Network Hardware Integration Research
> > Bell Labs, Lucent Technologies
> > 600 Mountain Avenue
> > Murray Hill, NJ 07974
> > Tel: (908) 582-3396
> > FAX: (908) 582-6228
> > email: mandich@lucent.com __________________________________________
> >
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-3-blade@listserv.ieee.org
> > [mailto:owner-stds-802-3-blade@listserv.ieee.org]On Behalf Of Altmann,
>
> > Michael W
> > Sent: Monday, November 29, 2004 6:55 AM
> > To: STDS-802-3-BLADE@listserv.ieee.org
> > Subject: [BP] Upcoming Signaling ad hoc conference calls
> >
> >
> > 802.3ap Task Force Members (Signaling ad hoc),
> >
> > Below are the schedule, bridge details and dial-in numbers for the
> > remainder of the .3ap Signaling ad hoc conference calls for 2004.
> >
> > All material for discussion in these meetings should be posted to the
> > reflector or web-site at least two days before the conference calls
> > (i.e. EOD on the Wednesday before each call). Per our recent interim
> > mtg discusions, please observe the deadlines discussed in the interim
> > meeting for updating submissions for the signaling spreadsheet. The
> > deadlines and ad hoc topics are below:
> >
> > Spreadsheet input deadlines to Signal Ad Hoc via reflector Nov. 30 -
> > Specific parameters for extension to spreadsheet Dec. 10 - Specific
> > values for all parameters in spreadsheet
> >
> > Signaling ad hoc Conference Call Topics
> > Dec. 3 - Define specific parameter changes, TP4 - TP5 link details and
>
> > packaging effects Dec. 17 - Define specific simulation parameter
> > values Dec. 10 - Provide complete test case channel data - all data
> > means through and crosstalk Jan. 19 - Submit simulation results for
> > entry into spreadsheet
> >
> > Regards.
> > .../Mike
> > Signaling ad hoc Conference Call Schedule
> > N.B.: The dial-in number for all meetings is the same. Local dial-in
> > numbers are provided below.
> > Date: Friday, December 3, 2004
> > Time: 10:00 US Pacific Time
> > Duration: 2 Hours
> > Chairperson: Michael Altmann
> > Bridge: 2 Passcode: 6297476
> > Date: Friday, December 17, 2004
> > Time: 10:00 US Pacific Time
> > Duration: 2 Hours
> > Chairperson: Michael Altmann
> > Bridge: 4 Passcode: 0666263
> >
> > Bridge Dial-In Numbers
> > Arizona
> > 480-552-2663
> > 480-715-2663
> > California
> > 949-567-4666
> > 916-356-2663
> > 858-391-1711
> > 408-765-2663
> > Colorado
> > 719-273-2663
> > Massachusetts
> > 978-553-2663
> > NewJersey
> > 973-967-6770
> > NewMexico
> > 505-794-2663
> > Oregon
> > 503-696-2663
> > 503-264-2663
> > South Carolina
> > 803-216-2246
> > Texas
> > 512-314-3030
> > Utah
> > 801-445-2663
> > Washington
> > 253-371-2663
> >
> >
> >
> > .../Mike