Re: [10GBT] PAM12 performance
Scott,
With regard to issue #1, I disagree that a 1dB difference in the transmit
PSD is "well below the measurements and setup errors" for the emissions
profile. Anyone who has spent hours and days meeting the FCC/CISPR
emissions profile in the range will know that 1dB will make a huge
difference between a pass and fail, since the likelihood of a fail would be
exponentially determined by this single dB.
With regard to issue #2, I would like you to clarify which of my following
assertions do you disagree with so that I can address your so-called
dispute(s) in a cogent manner:
a). PAM8 has 3.9dB better susceptiibilty penalty than PAM12 over a 0m cable.
b). PAM8 has 3.2dB better susceptibility penalty than PAM12 over a 55m Cat-6
cable (existing Cat-6 cabling),
c). PAM8 has 2.0dB better susceptibility penalty than PAM12 over a 100m
Cat-6 cable (new Cat-6 cabling).
Please present the technical basis for your contrary assertions with source
code, so that I have the wherewithal to correct your code, if necessary.
With regard to issues 3,4, and 5, I'm glad that you are planning to fix them
all. I look forward to receiving a detailed description of your proposed
fixes to these issues well in advance of the interim so that we can have an
useful debate over the fixes during the interim.
Regards,
Sailesh Krishna Rao.
------------------------------------------
Dr, Sailesh Krishna Rao, Ph. D.
Phyten Technologies, Inc.,
200 Daniels Way, Suite 110,
Freehold, NJ 07728.
(732)-845-2100
srao@phyten.com
------------------------------------------
From: Scott Powell <spowell@broadcom.com>
>Reply-To: spowell@broadcom.com
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: [10GBT] PAM12 performance
>Date: Fri, 20 Aug 2004 17:04:34 -0700
>
>Hi All,
> Achievable system performance is a function of the modulation rate +
>channel and is not a subjective issue. Last May, Dr. Ungerboeck clearly
>derived and presented the inherent achievable performance as a function of
>modulation rate based on established communications theory and the Task
>Force's channel models (ungerboeck_0504.pdf). As his analysis proves, the
>optimal modulation rate over our "worst case" channel has a broad optimum
>around 800Msps and is fairly insensitive to the shape of the transmit
>filter. Keyeye and Solar Flare (among others) have independently arrived
>at, and presented, similar conclusions on modulation rate quite some time
>ago. In July, Dr. Ungerboeck showed that the *inherent* performance of a
>970Msps system (8-PAM) and an 821Msps system (12-PAM) are very similar with
>12-PAM offering a small advantage. He further showed that practical
>transmit and receive filters can be introduced without a significant
>performance hit (ungerboeck_0704.pdf). There is no reason to believe that
>the performance of the 12-PAM and 8-PAM proposals currently on the table
>cannot be *improved* to the point where they offer similar performance - as
>predicted by theory. Improved framing, constellations, and coding schemes
>can be (and I'm sure are being) developed for both proposals to move them
>closer to their inherent performance.
>
> Over the last month, there have been over 150 postings on the "PAM-8 vs
>PAM-12" proposal selection issue. While a few of the discussions have
>been
>useful, there has been a good deal of "bombast, hyperbole, and snappy
>phrases" - as Hugh points out. In addition, a fair amount of unproductive
>time has been invested by all in understanding and countering
>misinterpreted
>claims, bug ridden code, and side issues that have little to do with the
>choice of modulation. In any case, all of this discussion does not change
>the fundamental conclusion clearly supported by previous Task Force
>presentations:
>
>===============================================
> The two competing proposals have similar inherent performance (slight
>edge for PAM-12) but the PAM-8 system must operate at 15-20% higher speed
>translating into higher power and increased implementation difficulty.
>===============================================
>
>
> Regarding the "5 issues" recently submitted to the reflector:
>
>1) Emissions. This was already addressed over numerous emails PAM-12 has a
>small advantage over some portions of the spectrum and a small disadvantage
>over others. The bottom line is, once again, both systems have similar
>performance and either one can be made to look worse or better than the
>other depending on the choice of transmit filter, the assumption of
>20dB/dec
>emissions increase, and the frequency range being considered. Note that
>fractions of a dB difference in emissions performance is well below the
>measurement and set-up error for emi scans and is not a compelling
>difference in either case.
>
>2) Susceptibility. This was also addressed over several emails. If the
>"solarsep" code is run (Salz solution) with increasing levels of background
>noise, the PAM-12 system shows a small advantage (~<1dB) over PAM-8.
>Similar results for increasing ANEXT. We can go into details at the
>interim
>but, again, the differences favoring PAM-12 but are not that compelling -
>the reduction in clock rate is. The argument about PSD variation with
>precoding coefficients because of the PAM12 "doughnut" constellation is not
>correct for any practical precoder. Susceptibility to external noise will
>be an issue for either system operating with unshielded cables.
>
>3) PAM12 Constellation. The "doughnut" constellation is obviously
>sub-optimal but doesn't mean a better one cannot be found. This doesn't
>change the fact that the *inherent* performance difference between a
>~820Msps system and a ~1000Msps system is small. The main advantage to the
>~820Msps system is that the transceiver can be operated with a lower rate
>clock. Again, arguments about the variation of PSD as a function of THP
>coefficients for the "doughnut" constellation is incorrect for any
>practical
>precoder.
>
>4) Framing Complexity. The importance of this is greatly overstated.
>Framing will be a tiny fraction of the complexity of a 10GBASE-T
>transceiver. If a simpler scheme is desired, this is straight-forward to
>change and is a side issue to the choice of modulation rate.
>
>5) Fixed Patterns. The claim that frame syncs "convey no information
>whatsoever" is self-contradictory -- the information conveyed is the
>location of the data frames. As was pointed out over numerous emails,
>frame
>sync's do not result in "peaky" transmit spectrums as was earlier claimed.
>Frame synchronization is another side issue to the choice of modulation
>rate. If there is a consensus within the TF that there is little system
>value in continuing to provide a sync pattern during customer data
>transmission, it can be removed except during startup. However, the
>savings
>is only 112/52833 ~= 0.2% overhead in doing so.
>
>
>In summary, items 1 & 2 are in dispute and have been previously addressed
>while items 4 & 5 can easily be modified and don't really have much to do
>with the choice of modulation rate. It would seem like the only real
>"issue" with the PAM-12 proposal which has not already been addressed is
>the
>constellation choice.
>
>Regards,
> - Scott
>
>Dr. Scott Powell
>Senior Manager, Ethernet PHYs
>Broadcom Corp.
>(949)926-5105
>spowell@broadcom.com
>
>
>
>-----Original Message-----
>From: stds-802-3-10gbt@ieee.org [mailto:stds-802-3-10gbt@ieee.org] On
>Behalf
>Of Hugh Barrass
>Sent: Thursday, August 19, 2004 4:01 PM
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] Summary of issues with PAM12
>
>
>Hal,
>
>I still maintain that the "hole in the constellation" is not an issue per
>se. It can be demonstrated that a PAM-12 solution *could* operate with a
>baud rate lower than 800Mbaud whereas the proposal in July showed a
>solution
>with a baud rate of 825Mbaud. If, this solution does not work then perhaps
>those who favor PAM-12 modulation might want to rethink their
>constellations. On the other hand, if the "inefficient" PAM-12 proposal is
>deemed workable and superior to any other proposal then perhaps the
>proponents like the "convenience" of 14 bits/baud instead of 14.33
>bits/baud.
>
>I find all of the bombast and hyperbole distracting. We are engineers; we
>can read graphs; we can review equations. I do not think that we should be
>making decisions based on who can coin the snappiest phrase or whether we
>get constellations made of chocolate. Can we please get back to the regular
>programming - post simulation results, analysis etc.
>
>Of Sailesh's list - the first and second a relevant points although there
>seems to be sufficient dispute over the details to warrant more analysis.
>The fourth point is a reasonable argument against the PCS proposal although
>it has no relevance to the modulation. The third and fifth points are
>redundant as the effects of inefficiency are taken into account by the
>increased baud rate. The last point is just plain dumb! Frame delineation
>is
>always overhead; fixed length frames are usually delineated by fixed
>patterns that contain no information other than the frame delineation -
>well, duh!
>
>Hugh.
>
>Roberts, Hal wrote:
>
> >Hugh,
> >
> >Ignoring the hilarious 'confidential' e-mails that this posting seemed
> >to have inspired, the 'hole in the constellation' just seems to me to
> >be a particularly obvious waste of margin in the PAM-12 proposal. What
> >I am really looking for is a PAM-12 proponent to summarize the issues
> >with PAM-8 (like Sailesh did for PAM-12) so as to make a comparison. So
> >far nobody has attempted to create this summary.
> >
> >Your analogy of an 'issue with PAM-8' being 'only 12 bits/baud' is not
> >a good one since trading bits per baud for increased baud rate is a
> >valid engineering trade off. It is not an outright inefficiency like
> >the constellation problem.
> >
> >Like Sailesh said, "Did 10GBASE-T become a greatly simplified problem
> >in the intervening period that these margins are no longer important?"
> >
> >Hal
> >
> >
> >
> >
_________________________________________________________________
Check out Election 2004 for up-to-date election news, plus voter tools and
more! http://special.msn.com/msn/election2004.armx