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
>