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...




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
>