Re: [10GBT] PAM12 performance
Hi Sailesh,
I think you must have misunderstood my statements - I really didn't say
I'd "fix" the items you point out. Maybe I wasn't clear enough. With
respect to #4 and #5, what I was trying to say is that these items do not
relate to the selection of modulation rate (PAM8 vs PAM12) - they apply to
both. Furthermore, I don't consider them "issues" or "problems" in the
first place - with either proposal. The framing and synchronization can be
improved for either proposal if the task force wishes - as you already
demonstrated by reducing the original 1000Mbps symbol rate through improved
framing. I think we should discontinue clouding the main issue - selection
of a modulation rate - with side issues that really should be addressed in
separate threads by the parties that think they need to be addressed.
At the risk of repeating myself, none of this changes the fundamental fact
that it has been clearly shown that the PAM-8 and PAM-12 proposals have
similar performance (slight edge for PAM-12), but the PAM-12 proposal offers
the advantage of a reduced operating frequency resulting in reduced power
and reduced implementation difficulties. Rather than providing source code,
I would refer you once again to the analysis already presented to the task
force in ungerboeck_0704.pdf and ungerboeck_0507.pdf presenting the inherent
performance possible from either proposal.
In addition, unless we want to consider multiple PHYs (a short reach PHY
and a long reach PHY), quoting performance at 0m and 55m is again not very
productive for the selection of modulation rate. The worst case channel
model has been shown to be channel model #3 at 100m (with 100m channel model
#1 a close second). As we all know, SNR margin increases for shorter
cables. As clearly shown in the rigorous analysis of ungerboeck_0704.pdf,
the SNR margin increases to over 5.5dB for the 55m channel model #2 - more
than double the SNR margin for the 100m model #3 - when the same PHY is used
in both cases. I believe the task force desires a *single* PHY capable of
operating over 100m of "improved" cat 6 so lets focus our attention on the
goal. Again, we can start a separate thread for those wishing to consider
optimizing a PHY for shorter reaches if there is interest in a dual-phy
idea.
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 sailesh rao
Sent: Saturday, August 21, 2004 1:30 AM
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: 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