RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel capacity estim...
Vivek--
A good summary.
1000BASE-T was a direct descendent of work done on 100BASE-T2.
The channel model was completed very early in 1000BASE-T. As I recall it
was developed by Chris DiMinico, Bob Campbell and Terry Cobb.
As you point out, there were multiple (at least four) competing technologies
Colin
------------------------------
At 09:27 AM 2/27/2003 -0600, Vivek Telang wrote:
>This is an excellent memory test for all the 802.3ab-ers out there, and I
>feel compelled to hit the buzzer. :)
>
>A lot of the simulation activity was actually done before the 802.3ab
>(1000BASE-T) PAR was approved**. But this might be somewhat misleading
>because the work was actually done under the 802.3z umbrella (before the
>copperheads were banished from that kingdom). But in any case, I remember
>the basic channel models being in place very early on.
>
>More importantly, I don't think technical feasibility (in a channel
>capacity sense) was ever debated in 802.3ab. This was because (IMHO) in a
>very early presentation 1000BASE-T was portrayed as an enhancement to
>100BASE-TX/100BASE-T2. The transmitted bandwidth in that proposal was the
>same as the 100BASE-TX system, and the PAM line code was derived from the
>100BASE-T2 system. The only additional technical challenge was the
>receiver DSP. To be sure, there were many other line codes presented (QAM,
>CAP, PR), but for PAR approval, the E-TX/T2 line code was all that was
>needed to provide the 802.3 audience with an existence proof of technical
>feasibility.
>
>**Historical timeline:
>The first set of presentations addressing 1000BASE-T feasibility were made
>in March '96.
>The 802.3ab PAR was approved in Jan '97.
>Clause 40 was approved in June '99
>
>Best regards,
>
>Vivek
>
>
> > -----Original Message-----
> > From: owner-stds-802-3-10gbt-modeling@majordomo.ieee.org
> > [mailto:owner-stds-802-3-10gbt-modeling@majordomo.ieee.org]On Behalf Of
> > William Jones
> > Sent: Wednesday, February 26, 2003 4:39 PM
> > To: Booth, Bradley; stds-802-3-10GBT-Modeling@ieee.org
> > Cc: stds-802-3-10gbt@ieee.org
> > Subject: RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel
> > capacity estim...
> >
> >
> >
> > Sreen or Chris
> >
> > Was the simulation activity for 1000BASE-T that you are referring
> > to done during the study group or done during the task force?
> >
> > regards
> > Bill
> >
> > -----Original Message-----
> > From: Booth, Bradley [mailto:bradley.booth@intel.com]
> > Sent: Wednesday, February 26, 2003 1:47 PM
> > To: stds-802-3-10GBT-Modeling@ieee.org
> > Cc: stds-802-3-10gbt@ieee.org
> > Subject: RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel
> > capacity estim...
> >
> >
> >
> > These messages haven't been making it to the reflector due to a bad word
> > match. The word has been deleted.
> >
> > Thanks,
> > Brad
> >
> > -----Original Message-----
> > From: "Sreen Raghavan" <sreen@myricanet.com>
> > To: <CDimi80749@aol.com>, <stds-802-3-10GBT@ieee.org>,
> > <stds-802-3-10GBT-Modeling@ieee.org>
> > Subject: RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel
> > capacity estim...
> > Date: Wed, 26 Feb 2003 13:33:09 -0800
> > Importance: Normal
> >
> > Chris:
> >
> > I recall the 1000BT simulation efforts quite vividly, and measured cable
> > models were a huge part of it. In my opinion, there should be two
> > aspects to the study we all are involved in for 10GBaseT:
> >
> > 1. Does the effort make sense from channel capacity calculations with
> > (a) limit lines and (b) measured models of CAT5 and CAT6 cables?
> >
> > 2. If the answer to (1) is yes, then we should discuss the selection of
> > the appropriate line coding method for such cables. If the answer to (1)
> > is no even simply based on 1(a), we may be better off considering a
> > better cabling system (CAT7 comes to mind but I am in noway not wedded
> > to it) and then proceed to choose the appropriate line coding for the
> > selected media.
> >
> > I do agree that we must confirm all our results with measured cable
> > models especially in step 2. I think by using calculations presented so
> > far regarding 1(a), we can easily eliminate some cabling choices for 100
> > meter transmission over twisted pairs, and focus our efforts on the
> > appropriate cabling systems.
> >
> > Regards,
> > Sreen
> >
> >
> > -----Original Message-----
> > From: CDimi80749@aol.com [mailto:CDimi80749@aol.com]
> > Sent: Wednesday, February 26, 2003 1:11 PM
> > To: sreen@myricanet.com; stds-802-3-10GBT@ieee.org;
> > stds-802-3-10GBT-Modeling@ieee.org
> > Subject: Re: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel
> > capacity estim...
> >
> >
> >
> > Sreen,
> >
> > The 1000BASE-T tutorial includes a presentation that Bob Cambell
> > (Lucent) and
> > I made addressing
> > Category 5 cabling models for line code simulations. The presentation
> > depicts
> > the "measured data" used
> > in the 1000BASE-T Matlab code to evaluate the 3 dB and 10 dB design
> > points.
> >
> > In 10BT, 100BT, and 1000BT we made many^10 (that's many to the 10th
> > power)
> > measurements
> > to validate and test the design(s). The measurements are the basis for
> > the
> > establishment of the
> > limits specified in those standards.
> >
> > Regards,
> >
> > Chris DiMinico
> >
> >
> >
> >
> >
> > In a message dated 2/26/03 2:00:19 PM Eastern Standard Time,
> > sreen@myricanet.com writes:
> >
> > << During 10BaseT, 100BaseTX, and 100BaseT standard developments, we
> > always
> > assumed insertion loss limit lines for analysis and simulations. This
> > would guarantee that every CAT5 or CAT5e cable will be able to achieve
> > error free performance at a distance of 100 meters and beyond. We
> > cannot
> > develop a standard based on "some measurements" of "some cables".
> >
> > I would also add that in reality, every manufacturer of 1000BaseT PHYs
> > satisfying the IEEE standard achieves well in excess of 100 meters of
> > CAT5 performance (Most manufacturers of 1000BaseT PHYs guarantee
> > error-free performance up to 140 meters). This extra distance is
> > required by most system vendors as they believe it provides additional
> > operating margin that they need. Based on my experience in LAN
> > transceivers (My colleagues and I built DSP-based 10/100/1000 PHYs that
> > are shipping in millions of quantities today), customers require
> > error-free performance, i.e., an error-rate that is orders of magnitude
> > below that specified in the standard. Hence, we must choose a solution
> > to 10GBaseT that has substantial built-in SNR margin.
> >
> > We at Vativ (formerly Myrica)have done substantial analysis work in
> > MATLAB regarding the feasibility of the approach presented by
> > Solarflare
> > at November 2002 meeting. The results we obtained are very similar to
> > those presented by both Z. Roth and X.Chen. We plan to share our
> > results
> > at the upcoming IEEE meeting in March 2003.
> >
> > In summary, based on almost any reasonable metric, the proposal by
> > Solarflare is an unworkable approach.
> >
> >
> > Sreen Raghavan
> > Vativ Technologies, Inc. (Formerly Myrica Networks, Inc.)
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-3-10gbt@majordomo.ieee.org
> > [mailto:owner-stds-802-3-10gbt@majordomo.ieee.org] On Behalf Of William
> > Jones
> > Sent: Wednesday, February 26, 2003 10:00 AM
> > To: Fakterman, Boris; George Zimmerman; stds-802-3-10GBT@ieee.org;
> > stds-802-3-10GBT-Modeling@ieee.org
> > Subject: RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel
> > capacity estim...
> >
> >
> > Boris
> >
> > Let me clarify two points. First, the interpretation of the graph is
> > that all residual noise sources combine to be below the noise level,
> > for
> > example, -140 dbm/Hz. This has a direct consequence with the
> > implementation of the cancellers. Second, this particular data used the
> > ISO insertion loss limit line. Using measurement based models will
> > yield additional SNR margin.
> >
> > regards
> >
> > Bill
> >
> > -----Original Message-----
> > From: Fakterman, Boris [mailto:boris.fakterman@intel.com]
> > Sent: Wednesday, February 26, 2003 3:48 AM
> > To: George Zimmerman; stds-802-3-10GBT@ieee.org;
> > stds-802-3-10GBT-Modeling@ieee.org
> > Subject: RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel
> > capacity estim...
> >
> >
> > George, All
> >
> > The primary purpose of the ongoing discussion was to decide if the
> > PAM10
> > design could exist on 100m CAT5 cable. Following the discussion I don't
> > feel
> > on the solid ground as tens dBs in SNR grow and fall mostly in
> > cancellation
> > ratio parameters. The Alien NEXT level and possible cancellation are
> > not
> > based with enough data.
> > The implications of the Echo, NEXT, FEXT cancellation ratio presented
> > by
> > Solarflare also are not clear to me. The cancellation ratio will be
> > impacted
> > by coefficients resolution in digital domain, by jitter and other
> > impairments in analog domain. Does the proposed cancellation ratio
> > demand
> > reasonably achievable analog and digital parameters?
> >
> > Meanwhile to promote the primary purpose I would like to refer to the
> > document distributed by William Jones few weeks ago (attached).
> > If I understand correctly it describes the SNR after the equalizer on
> > 100m
> > CAT5 with ground noise only. The SNR for -140dBm/Hz ground noise (no
> > Echo,
> > NEXT, FEXT) is roughly 28dB. Assuming coded signal SNR for BER 10^-10
> > as
> > 25dB, it remains only 3 dB margin for Echo,NEXT,FEXT, Alien NEXT and
> > implementation impairments.
> > Again if I understand correctly the graph, it seems that there will be
> > negative margin considering all noises exist.
> >
> > Regards,
> >
> > Boris Fakterman - Intel Communications Group, Israel
> > Tel: 972-4-865-6470, Fax: 972-4-865-5999
> > mailto:boris.fakterman@intel.com
> > -----Original Message-----
> > From: George Zimmerman [mailto:gzimmerman@solarflare.com]
> > Sent: Wednesday, February 26, 2003 3:24 AM
> > To: stds-802-3-10GBT@ieee.org; stds-802-3-10GBT-Modeling@ieee.org
> > Subject: RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel
> > capacity estim...
> >
> >
> > Xiaopeng & Zeev -
> > Respectfully, no matter how many times you say it, you continue to
> > grossly distort the proposals put forward. I have a plot generated by
> > Zeev's version of your code to show the input noise levels, which can
> > be
> > compared with the measurement-based models in the November tutorial. I
> > tried to attach just the relevant graphs from the tutorial, but the
> > reflector bounced it for size - you'll have to go to the web site.
> >
> > A few of the significant differences, some mentioned by Bill in an
> > earlier email are:
> > 1) Use of smooth limit lines vs. a measurement-based model (such as was
> > used for 1000BASE-T) scaled to worst-case. This is NOT "a couple of
> > dB", more like 4-6 dB, and, more importantly, changes the relationship
> > for the required cancellation.
> > 2) Do NOT use the "required cancellation" numbers we gave for
> > "achievable cancellation", and it is inappropriate to use them with
> > different line models. When there is more crosstalk, as has been said
> > before, it is often the case that more cancellation is achievable.
> > This
> > is often true because the root cause of the crosstalk has changed so
> > that it involves a shorter time delay with stronger coupling.
> > 3) As more noise sources are accounted for the "background" must be
> > reduced. We used -143dBm/Hz in the November tutorial & support that
> > (or
> > less, based on measurements) when Alien crosstalk is accounted for
> > separately, as was done in the capacity calculations in the tutorial.
> > (worth 3 dB)
> > 4) the Alien NEXT model is overly pessimistic, this is a discussion in
> > the modeling group. Not just the limit line, but data shows (see the
> > November presentation, not from us, but from Sterling & Avaya) that
> > actual Alien NEXT is significantly below (10 dB at least) the limit in
> > the higher frequencies.
> > 5) Zeev has incorrectly used 0 dB alien NEXT reduction in his code
> > under
> > "SolarFlare cancellation". We clearly show 10 dB relative to our
> > model.
> > If the Alien NEXT model is different, more cancellation is likely
> > possible. I can't say without seeing a cable & the model. You can't
> > just adjust the model keep the cancellation fixed, they are related.
> > (10
> > dB improvement)
> >
> > So, we're seeing more than 20 dB pessimism here. I'd scarcely say "a
> > couple dB". It's a pretty gross misrepresentation. What we need to do
> > is wait for code using proper models.
> >
> > George Zimmerman
> > gzimmerman@solarflare.com
> > tel: (949) 581-6830 ext. 2500
> > cell: (310) 920-3860
> >
> > -----Original Message-----
> > From: xichen@marvell.com [mailto:xichen@marvell.com]
> > Sent: Tuesday, February 25, 2003 2:25 PM
> > To: Ze'ev Roth
> > Cc: stds-802-3-10GBT-Cabling@ieee.org;
> > stds-802-3-10GBT-Modeling@ieee.org; stds-802-3-10GBT@ieee.org
> > Subject: RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel
> > ca pacity estim...
> >
> >
> > Ze'ev,
> >
> > Thank you for your message. Your observation is right. I thought that
> > the
> > -140dBm/Hz background noise level is a double-sided PSD when I got it
> > from
> > the document. Either reducing the background noise by 3dB or
> > increasing
> > the input signal PSD by 3dB should fix the problem. You have also
> > provided the capacity results after the modification. They basically
> > tell
> > us the same story we have been facing.
> >
> > Of course the smooth limit line model used in the program will be
> > replaced
> > by the scaled, selected, measured channel data when they are offically
> > available. Only couples of dB SNR improvement to performance based on
> > the
> > channel limit model should be expected. Once we obtain more accurate
> > results on the channel capacity, we will be able to to assess our
> > achievable targets for the 10GBT standard.
> >
> > Regards,
> >
> > Xiaopeng
> >
> >
> >
> >
> >
> >
> >
> > "Ze'ev Roth" <zeevr@mysticom.com> on 02/25/2003 05:50:48 AM
> >
> > To: "'xichen@marvell.com'" <xichen@marvell.com>, CDimi80749@aol.com
> > cc: stds-802-3-10GBT-Cabling@ieee.org,
> > stds-802-3-10GBT-Modeling@ieee.org, stds-802-3-10GBT@ieee.org
> >
> > Subject: RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a
> > channel
> > ca pacity estim...
> >
> >
> > Xiaopeng hi,
> > Very good work.
> >
> > In order to probe into this deeper, I initially simplified your
> > simulation
> > to having only a single simple impairment - background noise (i.e., I
> > removed from your simulation all other impairment: NEXT, FEXT, ANEXT,
> > ECHO).
> > The resulting capacity was 15.29Gbit/sec.
> > This simplification allows me to compare your results with my
> > program's
> > results. Running my routine on same parameters I got capacity of
> > 17Gbit/sec.
> > So clearly there was a discrepancy in the results.
> > Previously I've cross checked my routine on simple problems and
> > compared
> > to
> > textbook results, as well as put it to scrutiny with a several
> > colleagues,
> > so I am quite confident it yields correct results.
> >
> > Therefore, I dug a bit into your equations (in the Matlab file), I
> > think
> > there is a slight problem with the definition of spectral density (it
> > doesn't account for double sided) - there is a subtlety in capacity
> > equations (the usual 3dB problem) and I think you may have fallen into
> > this
> > pit. And indeed when I add 3 dB to the noise floor in my simulation I
> > get
> > capacity of 15.327. The difference from 15.29 can probably be
> > attributed
> > to
> > a different frequency grid and that I used an older version of the
> > insertion
> > loss limit equation which is marginally different than the one you've
> > used.
> >
> > I've taken the liberty to modify your code (I started out with the
> > latest
> > version you've sent) to account for the double sided density (one can
> > easily
> > switch between the original code and my correction) and attached it
> > herein.
> > I've added comments showing were the single sided - double sided
> > spectral
> > density switch occurred in my opinion. I've also added a sanity check
> > option for simple AWGN channel case.
> >
> > Running the modified program I got the following results:
> > Cable=CAT-5E Cancellation=Marvell Capacity= 8.89 Gb/sec
> > Cable=CAT-6 Cancellation=Marvell Capacity=11.36 Gb/sec
> >
> > I've also added the option to use Solarflare's figures for
> > impairements'
> > DSP-improvement as presented in Kauai.
> > Running the modified program under these assumptions yields:
> > Cable=CAT-5E Cancellation=SOLARFLARE Capacity=5.57 Gb/sec
> > Cable=CAT-6 Cancellation=SOLARFLARE Capacity=7.26 Gb/sec
> >
> > Summarizing, although there was a small flaw in the original M file,
> > your
> > basic conclusions seem to hold water and moreover using Solarflare's
> > assumptions regarding DSP cancellation performance yield that neither
> > CAT5E
> > nor CAT6 can support 10Gb/sec for 100m cable length.
> >
> > Regards,
> > Ze'ev
> > Mysticom
> >
Colin K. Mick
The Mick Group
2130 Hanover St,
Palo Alto, CA 94306
voice: (650) 856-3666
FAX: (650) 494-3737
email: ckm@mickgroup.com
URL: www.mickgroup.com