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/