Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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