Dueling Interconnects Unmasked

Recent news of the HyperTransport Technology Consortium draws attention to an increasingly public duel between two technologies aimed at speeding up throughput on today's high-speed networks (see 'HyperTransport' Consortium Grows).

Those two technologies are HyperTransport and RapidIO (which has its own banner group, the RapidIO Trade Association). Both are chip-to-chip interconnection techniques aimed at ensuring that the inner workings of network and storage gear won't wind up being a bottleneck as carriers move to ever faster services.

A quick backgrounder: Today, networking devices that deploy multiple processors typically rely on the PCI bus or similar techniques to process information, such as packet lookups, inside a box. These technologies have maximum data rates of about 1 Gbit/s today (with exceptions), and they don't support varying amounts of bandwidth in one device.

But speed and bandwidth flexibility will be required of mainstream storage and networking gear as networks move to 10 Gbit/s data rates and beyond. For example, OC192 network processors supporting functions for next-generation Sonet switches will need to get lots of data on and off their chips fast.

Enter HyperTransport and RapidIO, which were devised by different vendors to speed up devices based on their chips. Simply put, both are ways of ensuring that complex, multiprocessor boxes will perform as well as the high-speed networks they're meant to run on.

Neither HyperTransport nor RapidIO are alternatives to Infiniband, which is designed to improve the I/O in servers and between subsystems instead of between chips (see InfiniBand Trade Association). Both HyperTransport and RapidIO proponents say their designs work with Infiniband.

Intel Corp. (Nasdaq: INTC) is often cited as having its own interconnect program, called 3GIO or Arapahoe. But by all accounts, this is not up to speed with HyperTransport or RapidIO. "Intel is a latecomer," says Bert McComas, founder and principal analyst at InQuest Market Research, a consultancy and market research firm. With less bandwidth and scaleability than either HyperTransport or RapidIO, by the time 3GIO is ready for market, about 2004, it's unlikely to be any competitive threat to the others, in McComas's view.

Meanwhile, both HyperTransport and RapidIO have a lot in common: They are designed to link chips, network processors, and other components inside multifunction devices based on silicon semiconductors. They are packet-based. They support varying bus widths and bandwidth rates. They are geared to support power and design efficiency. They both deploy so-called source-synchronous technology, where data and clock signals are sent over different connections that use the same voltage. They use similar signaling, based on the Low Voltage Differential Signaling specs approved by standards groups worldwide. And each claims to run at speeds above 60 Gbit/s chip to chip.

Table 1: Interconnect Techniques Compared
HyperTransport RapidIO
Main backers AMD, API Networks Motorola, IBM
Consortium URL www.hypertransport.org www.rapidio.org
Clock speeds 200 MHz to 800 MHz 100 MHz to 1 GHz
Bus widths 2,4,8,16, and 32 bits 8 or 16 bits
Number of pins 24 for 2-bit to 197 for 32-bit 40 for 8-bit; 76 for 16-bit
Aggregate bandwidth 128 Gbit/s 3 to 60 Gbit/s
Power required 1.2 volts 2.5 volts

But HyperTransport and RapidIO differ in several key ways, starting with pedigree. HyperTransport's creator and main backer is Advanced Micro Devices (NYSE: AMD), and originally it was geared to MIPS processors used in high-end servers and similar gear. More recently, API Networks Inc. has assumed a leading role as well. Broadcom Corp. (Nasdaq: BRCM) and PMC-Sierra Inc. (Nasdaq: PMCS) also license the technology.

RapidIO was originated by Motorola Inc. (NYSE: MOT) and IBM Corp. (NYSE: IBM) and is geared to Power PC processors, including those used in chassis-based equipment. This has given it early inroads with makers of networking gear. Alcatel SA (NYSE: ALA; Paris: CGEP:PA), Lucent Technologies Inc. (NYSE: LU), and Nortel Networks Corp. (NYSE/Toronto: NT) are all part of its steering group.

These early distinctions are getting increasingly blurry. Cisco Systems Inc. (Nasdaq: CSCO), for instance, belongs to both groups, as does Xilinx Inc. (Nasdaq: XLNX).

"There are many dependencies as far as selecting one or the other," says InQuest's McComas. He feels the key differentiators are more fine-grained and have to do with the practical considerations faced by product designers.

HyperTransport, for example, can often be implemented at lower cost because it uses fewer pins and lower voltage. Also, its supporters have put considerable effort into making sure HyperTransport works with PCI bus devices.

”HyperTransport might be considered a technology closer to the mainstream, high-volume implementations,” McComas says.

Until recently, there also were differences in how each technique worked with multiprocessor arrays. In most HyperTransport setups, when one processor in a row wants to talk to, say, the tenth processor, it must “daisy chain” its way through all of the intervening processors. RapidIO, in contrast, supports a peer-to-peer approach that is closely akin to switching. Since storage and networking gear usually deploy multiple processors, this could be a key factor in choosing one tack over the other.

But this differentiator appears to be dwindling. Earlier this month, API Networks released a product called the Starfish, a switch designed for use in HyperTransport networks. While details are comprehensible only to chip experts, API spokespeople say the Starfish works by replacing HyperTransport’s bus approach with a point-to-point architecture.

Still, those who wish to put a switch setup into a HyperTransport group of processors must pay API to do so, unless they want to create their own.

Ultimately, it seems the distinctions between HyperTransport and RapidIO are getting fewer and harder to discern, at least to outsiders. "There’s nothing I can point my finger at to say, ‘This is a feature that’s better in HyperTransport or RapidIO,' " says an engineer (who requested anonymity) from a chip vendor that supports both groups. "You can say that HyperTransport is cheaper, but that’s not always the case. There’s little technical difference, and performance is basically the same.”

In the end, it may come down to relationships. And that's not an easy field to navigate under any circumstances.

"There are alliances and pools of alliances that can be drawn along processor lines and by loyalty," says McComas, who points out that such alliances can shift. "It's not black and white."

— Mary Jander, Senior Editor, Light Reading
<<   <   Page 2 / 2
BlueWater66 12/4/2012 | 7:33:40 PM
re: Dueling Interconnects Unmasked SMP (Sym. Multi-Processing) Routers? I have been seeing a trend among Carrier Class Router Vendors to offer multi-bay, expandable routers. A common architecture includes port shelves and switching shelves. It seems as if the switching shelves can be expended in a fashion that looks like a SMP architecture, adapted to expandable switching fabrics. Are any of these based on an SMP model?? Will these evolve in direction?
skeptic 12/4/2012 | 7:33:39 PM
re: Dueling Interconnects Unmasked At COMDEX the Infiband crowd was there showing itGÇÖs wares and touting the grandness of their product, fair enough. One of the GÇ£selling pointsGÇ¥ was the lack of CPU power to support the TCP stack, the stack is in the chips so they say. Can someone who is a bit more software centric than I, please explain, using small words because IGÇÖm a hardware guy, why this is needed.
It isn't needed. TCP-IP (in all systems not
from microsoft) is very low-cost already.

The infiband crowd are following in a long
tradition of trying to displace TCP-IP with
a "better" technology. Some early ATM people
claimed that AAL-5 was going to be a TCP-IP
replacement. And there are even older
technologies that were aimed at replacing
TCP-IP networking but they all fail in part
because none of them really understand the
problems or TCP performance issues.

skeptic 12/4/2012 | 7:33:39 PM
re: Dueling Interconnects Unmasked
All I will say is the take everything that
QNX says about its OS and SMP with a great
deal of caution. It sounds good but reality
is going to be a whole lot different. If you
want performance, the application has to be
deeply involved in SMP. If you just ignorantly
create threads and semaphores, you will end
up with a system that is potentially slower
and far less reliable than a non-SMP system.

And expect a whole lot more defects to shake
out of the software. And just because you
are running threads on a single processor today
doesn't mean that you know where all the
threading and locking bugs are in the code.

<<   <   Page 2 / 2
Sign In