RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel capacity estim...
Bill,
Sreen is right. The simulations for 1000BASE-T all used Cat5 modeling data. The only exception was that for FEXT, we used models provided by Chris, and the other cable guys. These FEXT specs were later ratified in the Cat5e spec. Also, the simulations used data that was specified out to 100MHz. I don't quite remember if the "official" Cat5 standard supported this, or whether the 100MHz data also came from Chris et al.
Vivek
> -----Original Message-----
> From: owner-stds-802-3-10gbt@majordomo.ieee.org
> [mailto:owner-stds-802-3-10gbt@majordomo.ieee.org]On Behalf Of Sreen
> Raghavan
> Sent: Thursday, February 27, 2003 1:47 PM
> To: 'William Jones'; 'Vivek Telang'; 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...
>
>
>
> I was in attendance at most of the 1000BT meetings, and I could
> confidently say you were incorrect. We never argued about capacity of
> CAT5 cables. In addition, when we discussed specific line code
> proposals, there was a 3-dB and 10-dB margin design points for
> complexity evaluation. The margin was with respect to SNR needed to
> achieve 100 meter distance over CAT5.
>
> Sreen
>
> -----Original Message-----
> From: William Jones [mailto:wjones@solarflare.com]
> Sent: Thursday, February 27, 2003 11:32 AM
> To: Sreen Raghavan; Vivek Telang; 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
>
> It was questionable whether 1000BASE-T would run on CAT5. That was the
> impetus to qualification testing and CAT5e. There must have been doubts
> about whether it would work.
>
> Bill
>
> -----Original Message-----
> From: Sreen Raghavan [mailto:sreen@myricanet.com]
> Sent: Thursday, February 27, 2003 10:08 AM
> To: 'Vivek Telang'; 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...
>
>
>
> Vivek:
>
> I agree with your summary. Most importantly, there never was any
> discussion in 802.3ab as to whether 1Gbps over CAT5 was achievable. The
> only discussion was regarding line codes, and the associated DSP and
> analog front end requirements.
>
> Sreen
>
> -----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
> Vivek Telang
> Sent: Thursday, February 27, 2003 7:27 AM
> 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...
>
>
> 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
> >
>
>
>
>
>