Re: [10GBT] PAM12 performance
Hi Scott,
There is no need to separate the PHY solution, since PAM8 is more optimum
than PAM12 over all line lengths, from 0m to 55m to 100m.
The analysis in ungerboeck_1_0504.pdf and ungerboeck_1_0704.pdf are not
relevant for two reasons:
1. They compare hypothetical systems, not the two proposals on the table.
2. They do not consider EMI susceptibility margins.
Regards,
Sailesh 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: Re: [10GBT] PAM12 performance
>Date: Sun, 22 Aug 2004 12:55:24 -0700
>
>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
_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/