Re: [10GBT] Summary of issues with PAM8
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/