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