Re: [10GBT] Summary of issues with PAM8
Jose,
The PAM12 proposal is indeed using a less efficient LDPC code (rate=0.81)
than the PAM8 proposal (rate=0.84), but it didn't have to.
Regards,
Sailesh.
srao@phyten.com
>From: Jose Tellado <JTellado@TERANETICS.COM>
>Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] Summary of issues with PAM8
>Date: Fri, 27 Aug 2004 17:58:48 -0700
>
>Sailesh,
>
>The error in your analysis below is that you have assumed the LDPC code
>in the PAM8 proposal, which has almost twice the latency of the PAM12
>proposal.
>
>The formula for minimum (no overhead) symbol rate with 65B/64B is given
>by
>
>10G*(65/64)/4/(coderate*codedbits + uncodedbits)
>
>Thus the minimum symbol rate for an ideal PAM12 based on the
>LDPC(833,1024)
>in our July'04 proposal (about half the latency) is
>
>10000*(65/64)/4/(833/1024*2+log2(3)) = 790MHz
>
>Thus our total overhead for sync, framing, PLL VCO frequency which is a
>multiple of 25MHz, PHY control, PAM12 etc is about 825/790-1 = 4.4%,
>which is equivalent to about 64B/67.8B
>
>
>On the other hand, the July'04 PAM8 proposal with the larger latency
>block LDPC(1723,2048) has an overhead of about 64B/68.7B which is much
>closer (just need to round it :) to the "number" you had in your mind
>
>10000*(68.7/64)/4/(1723/2048*2+1) = 1000MHz
>
>Cheers,
>Jose
>
>PS I know you have recently fixed your symbol rate to be more efficient
>by implementing several PAM12 proposal concepts, but we have mentioned
>that the PAM12 framing/symbol rate was an example that can be further
>optimized as well.
>
>
>-----Original Message-----
>From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On
>Behalf Of sailesh rao
>Sent: Wednesday, August 18, 2004 7:29 PM
>To: STDS-802-3-10GBT@LISTSERV.IEEE.ORG
>Subject: Re: [10GBT] Summary of issues with PAM12
>
>Jose,
>
>The 780Ms/s symbol rate includes all the necessary overhead for the
>64B/65B etc. Therefore, the extra overhead in relation to the 64B/65B
>overhead for the hole in the constellation is
>
>577/156.25 = 3.69 ~= 4
>
>When added to the pre-existing 64B/65B encoding, this becomes the
>equivalent of 64B/69B encoding.
>
>Sailesh.
>srao@phyten.com
>
> >From: Jose Tellado <JTellado@TERANETICS.COM>
> >Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
> >To: STDS-802-3-10GBT@listserv.ieee.org
> >Subject: Re: [10GBT] Summary of issues with PAM12
> >Date: Wed, 18 Aug 2004 17:45:52 -0700
> >
> >Sailesh,
> >
> >Not sure what you had in mind, since this is not a mathematical
> >coincidence ...
> >
> >If you check your math more carefully, at 825MHz the optimum PAM12
> >could carry at most 64B/67B. 64/69 would require 840MHz (actually
> >higher if you include some LDPC framing and PHY control overhead such
> >as THP updates, etc.)
> >
> >Cheers :)
> >Jose
> >
> >
> >-----Original Message-----
> >From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On
> >Behalf Of sailesh rao
> >Sent: Wednesday, August 18, 2004 3:43 PM
> >To: STDS-802-3-10GBT@listserv.ieee.org
> >Subject: Re: [10GBT] Summary of issues with PAM12
> >
> >Hugh,
> >
> >Let's calculate the overhead due to the hole in the PAM12 constellation
>
> >once again. As you know, I've variously stated that the "optimum" PAM12
>
> >symbol rate should have been in the neighborhood of 780Ms/s. In
> >comparison with the proposed symbol rate of 825Ms/s, the overhead is
> >
> >(825-780)/780*10000 Mb/s = 577Mb/s
> >
> >In contrast, the overhead due to the 64B/65B encoding is
> >
> >1/64*10000 Mb/s = 156.25Mb/s
> >
> >Therefore, the hole in the constellation is equivalent to doing a
> >64B/69B encoding in PAM12. (No flames please, this is a mathematical
> >coincidence and no double entendre intended)
> >
> >Regards,
> >Sailesh Rao.
> >srao@phyten.com
> >
> > >From: Hugh Barrass <hbarrass@CISCO.COM>
> > >Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@LISTSERV.IEEE.ORG>
> > >To: STDS-802-3-10GBT@LISTSERV.IEEE.ORG
> > >Subject: Re: [10GBT] Summary of issues with PAM12
> > >Date: Wed, 18 Aug 2004 09:42:26 -0700
> > >
> > >Hal,
> > >
> > >I don't understand why the "hole in the constellation" is seen as an
> > >issue. It causes the PAM-12 to be less "efficient" than it could be,
> > >just like the padding bits and encapsulation overhead. The net result
>
> > >is that the proposal using PAM-12 needs a symbol rate of 825Mbaud
> > >where
> >
> > >a lower clock rate might be used if the efficiency was better.
> > >However,
> >
> > >if the comparison is made using that proposal and PAM-12 still comes
> > >out better then perhaps the "inefficiency" is acceptable. If, on the
> > >other hand and as Sailesh maintains, the comparison comes out in
> > >favor of
> > >PAM-8 then the PAM-12 proponents might want to look at ways of
> > >"trimming the fat."
> > >
> > >It would be equally valid to raise the "issue with PAM-8" of "only 12
>
> > >bits/baud" and require the PAM-8 fans to address that...
> > >
> > >Personally, I think 10GBASE-T would be best addressed by 4 pair,
> > >bonded, 2BASE-TL on steroids :-)
> > >
> > >Hugh.
> > >
> > >
> > >
> > >Roberts, Hal wrote:
> > >
> > >>All,
> > >>
> > >>Sailesh provides a nice compact list of (his) issues with regard to
> >PAM12.
> > >>I
> > >>have seen responses to some of these but nothing addressing or
> > >>summarizing them all.
> > >>
> > >>In addition it would be useful (at least to me) to see a similar
> > >>summary of "Issues with PAM8" from a PAM12 proponent. (Unless based
> > >>on
> >
> > >>Sailesh's
> > >>criticisms there are no longer any PAM12 proponents? ;-)
> > >>
> > >>Finally, Sailesh has a good point that a number of his issues have
> > >>been completely unanswered. I am surprised no one has addressed the
> > >>'hole in constellation' issue.
> > >>
> > >>
> > >>
> > >>
> >
> >_________________________________________________________________
> >On the road to retirement? Check out MSN Life Events for advice on how
> >to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
>
>_________________________________________________________________
>Express yourself instantly with MSN Messenger! Download today - it's
>FREE!
>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfeeŽ
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963