Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*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...*From*: "George Zimmerman" <gzimmerman@solarflare.com>*Date*: Tue, 25 Feb 2003 17:24:15 -0800*Sender*: owner-stds-802-3-10gbt@majordomo.ieee.org*Thread-Index*: AcLdHTGVsG+9pD4xR1WfPEHoUkLOiwACAL+Q*Thread-Topic*: [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

- Prev by Date:
**RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel capacityestim...** - Next by Date:
**[10GBASE-T] test** - Prev by thread:
**RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel capacity estim...** - Next by thread:
**RE: [10GBT-Modeling] RE: [10GBT-Cabling] [10GBASE-T] a channel capacity estim...** - Index(es):