Re: 850 nm solutions
Ed,
XAUI has nothing to do with a 10.3125 Gbaud line rate. That rate is associated
with the overhead of 64B/66B: 66/64 * 10 = 10.3125. Where are you getting this
information?
FYI: XAUI is proposed as an 8B/10B 4-lane serial interface with each lane
running at 3.125 Gbaud.
Please refer to:
http://grouper.ieee.org/groups/802/3/ae/public/mar00/taborek_1_0300.pdf
for further details.
--
Best Regards,
Rich
Edward Chang wrote:
>
> Comments:
>
> I agree XAUI should be 100% transparent. XAUI has its unique value in 10
> Gbps serial application to maintain symbol rate at 10.3125 which is very
> close to 10 Gbps. However, it comes with a lot of complicated coding
> manipulations.
>
> For CWDM approach, the data rate is low which, does need XAUI approach. The
> straight forward, mature, and market-proved block code will do nice job. In
> the reference model, it will completely skip the XAUI of 64b/66b, and the
> MAC will go directly to 8B/10B coding (PCS) followed by SERDES (PMA). Just
> the same as GbE ... simple and cost-effective.
>
> If the XAUI proposal is trying to make all applications using XAUI of
> 64b/66b, it is a wrong approach. Keep it flexible. Not everyone needs the
> complex manipulation of the coding scheme.
>
> Regards,
>
> Edward S. Chang
> NetWorth Technologies, Inc.
> EChang@xxxxxxxxxxxxxxxx
> Tel: (610)292-2870
> Fax: (610)292-2872
>
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Roy Bynum
> Sent: Wednesday, May 03, 2000 1:28 AM
> To: THALER,PAT (A-Roseville,ex1); stds-802-3-hssg@xxxxxxxx
> Subject: Re: 850 nm solutions
>
> Pat,
>
> There is nothing evil about economic and business considerations. I
> recognize the economic advantage of developing silicon that
> will work in multiple standards. I recognize that the cost of talented
> personnel along with other manufacturing and competitive
> issues tends to favor reduction of diversity. I recognize that there may
> be individuals in the P802.3ae TF that stand to benefit
> directly, or whose company would benefit economically depending on how the
> standard is defined. There is nothing evil about that.
> As a customer, the only benefit that I or the company that I work for
> receives, is the manor in which the users would be enabled by
> the standard.
>
> As a customer who deploys very high bandwidth and extremely large networks,
> I want consistent standards, but I want them specialized
> for the functions they are to perform. Over the years, the larger vendors
> have created more "generalized", like Microsoft's Windows
> NT. For mediocre desktop and server usage it will do. For people that
> require better or more reliable performance go to other
> vendors and products. While this may not have greatly effected Microsoft's
> market in low end systems, it has almost no share in the
> very high end technology market. 10GbE is targeted at the high end
> technology market. The 10GbE WAN compatible PHY is targeted for
> an extremely large but very specialized market. As a representative
> customer of that high end technology industry market, I would
> prefer to have what I need in the standard, "up front". Instead I may have
> to shop around for vendors that will deviate from that
> standard in order to deliver what is required, much like some large
> customers requiring vendors to support jumbo frames. This was
> also the comment by another customer concerning the need for short reach
> 10GbE interfaces.
>
> The majority of the individuals in the P802.3ae TF are "LAN" people. They
> understand the needs of a LAN only PHY. There are some
> that also work with WAN systems. Both the "LAN" and "WAN" people recognize
> that the needs are different between LAN systems and WAN
> systems. An attempt to combine the LAN and WAN into one "UniPHY" will
> result in a standard that does not properly address the needs
> of either the LAN or the WAN.
>
> Last year, 1.6 terabit per second DWDM systems were field tested. Those
> transport systems can provide 160 10GbE WAN channels per
> fiber. Internet content sites are increasing exponentially all over the
> world, with aggregated transport bandwidths getting into
> the 10s of terabits per second per site. Facilities floor space density is
> becoming a critical issue. The port density as well as
> per port bandwidth on data switches and servers is becoming a critical
> issue. The complexity of intra-cluster port usage in storage
> servers as well as data switches is becoming a critical issue. All of this
> is leading to the need for data switches with multiples
> of terabits per second in aggregate bandwidth per chassis, and interface
> cards with multiple 10Gb ports each.
>
> The industry needs very condensed form factor equipment, the kind that will
> not need to have 18" of etch between the MAC and PCS.
> The industry needs a protocol that has as much bandwidth efficiency as
> possible because the transport signaling speed is fixed.
> The industry needs transport operations and performance management based on
> existing systems so that it does not have to deploy
> entirely greenfield operations support systems as well as untried greenfield
> transport technology.
>
> It is the above reasons that I, as a customer, have taken a stand that XAUI
> should be 100% transparent as far as the standard is
> concerned. This will allow vendors in the future to build very high density
> systems, with small form factors per port, without the
> additional symbol overhead that a non-transparent XAUI would put on non-XAUI
> MAC/PCS interfaces. At the same time, a transparent
> XAUI will allow vendors to build systems today that do need the extended
> etch distance. As a customer, I have taken a stand that
> the LAN PHY and the WAN compatible PHY should be separate tracks within
> P802.3ae, according to the objectives as written. This will
> allow for short reach block encoded parallel solutions for the LAN PHY and a
> single serial scrambled synchronous solution for the
> WAN compatible PHY. As a customer, I have also taken a stand that the SONET
> mapping proposal by Paul Bottroff and David Martin,
> modified to allow for 10Byte IPG compression, be standardized instead of the
> 64B/66B block encoding for the WAN compatible PHY.
> This will allow for the highest data transfer bandwidth available with the
> shortest amount of time to market.
>
> Thank you,
> Roy Bynum
>
> ----- Original Message -----
> From: THALER,PAT (A-Roseville,ex1) <pat_thaler@xxxxxxxxxxx>
> To: Roy Bynum <rabynum@xxxxxxxxxxxxxx>; THALER,PAT (A-Roseville,ex1)
> <pat_thaler@xxxxxxxxxxx>; Rick Walker
> <walker@xxxxxxxxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
> Sent: Monday, May 01, 2000 7:05 PM
> Subject: RE: 850 nm solutions
>
> > Roy,
> >
> > This is a frustrating discussion. You seem intent on twisting what is said
> > and implying evil actions. I did not say different groups developed Hari
> and
> > XAUI. What I said is that the Infiniband TA did not develop Hari. I should
> > know, I've been there from the beginning and in the Future IO before that.
> >
> > Over my career, I've seen a number of times when separate groups applied
> > existing technologies to the same or similar problems and came up with
> > similar solutions. For instance, there were about 4 proposals for 10BASE-T
> > developed independently by different companies that when examined were
> > almost identical. It wasn't because we co-developed them. It was because
> > taking as a departure point what we had learned about twisted-pair cable
> > as an industry and applying that to how to run Manchester code over it,
> > a certain direction was fairly attractive and 4 out of 6 companies
> > investigating
> > it came up with very similar solutions. There were minor differences such
> as
> > the
> > choice of where to put the equalizer, but mostly it was the same solution.
> > That is the source of much of the "commonality" to which you refer.
> >
> > "Hari" was developed with Ethernet in Fibre Channel in mind (to the best
> of
> > my
> > understanding; I did not work in that group). But Hari as a name really
> > didn't fit into the names 802.3 has used for interfaces. Therefore, a
> > proposal
> > based on the Hari work suggests "XAUI" as a name that does fit in with
> > traditional Ethernet interface names.
> >
> > I have no idea what you are talking about when you talk about different
> > groups with the same people. Your statement about voting blocks is totally
> > unjustified and offensive.
> >
> > Sincerely,
> > Pat Thaler
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com