InfiniBand Drivers Released for Xserve G5 Clusters
A user writes, "A company called Small Tree just announced the release of InfiniBand drivers for the Mac, for more supercomputing speed. People have already been making supercomputer clusters for the Mac, including Virginia Tech's third-fastest supercomputer in the world, but InfiniBand is supposed to make the latency drop. A lot. Voltaire also makes some sort of Apple InfiniBand products, though it's not clear whether they make the drivers or hardware."
I've always understood that Myrinet is one of the better latency products available.
s p?content=9
And it has MacOSX Drivers:
http://www.myri.com/scs/macosx-gm2.html
Myrinet is used by 39% of the Top500 list published in November 2003
http://www.force10networks.com/applications/roe.a
It's as much crap as other technologies like IEEE 1394 (Firewire). Greg is concerned with the patent licensing requirements for Infiniband, which is a valid concern, but is no different than the requirements for other technologies that have support under Linux.
In particular, Infiniband requires licensing under RAND terms, similar to that of IEEE 1394.
You needn't be so snippy about it. If you had done any research at all into it you'd know that it was, indeed, in the #3 position but wasn't ranked at all last time around because it was down for an upgrade. They're moving from dual processor G5 desktop machines in the cluster to all G5 Xserves and since all the nodes weren't up during the official ranking period it doesn't appear on the list. Look for it to make a strong appearance again in the near future.
You seem like the type that needs proof, so here's the previous list.
You obviously have no clue as to what Infiniband is or is capable of. First off 4x Infiniband is 10 times faster then Ethernet at 10 gigabits/sec.
4X infiniband is 10 Gb/s signal rate but actually 8 Gb/s data rate (8b/10b encoding). This is one of many facts that the IB marketing dept. keep forgetting (I keep telling them, but they won't listen for some reasons).
GigE and TCP are quite inefficient when compared to Infiniband
TCP over Infiniband is as inefficient, it has nothing to do with GigE. People use IP over GigE because it's convenient, but you can use GigE without IP if you talk directly to the hardware. Some have tried and are still trying http://www.disi.unige.it/project/gamma/, but the main problem is the lack of hardware documentation from GigE vendors and the short life span of GigE chips.
I even read that a 1024 node cluster using GbE was just as fast as a 256 node cluster using IB
It's interesting to note that there are not many 256 nodes clusters in production with IB at the moment, even less with 1024 nodes. Second, just as fast doing what ? A pointless benchmark specially tuned for Infiniband as the IB supporters are used to publish or real-world applications ? Yes, high speed interconnects make a difference but GigE is just fine for a lot of the HPC applications I have seen so far.
So before you start talking out of your ass do some research like I did.
Don't believe everything you read, and don't drink the cool-aid that fast. Look at the Top500 just to see what machines are out there, not for the ranking (Linkpack is useless). You will see that there are quite a lot of GigE clusters and not that many IB ones. It's a matter of economics: if IB makes sense, people will buy it. These days, they buy much more GigE (or other) than IB.
What's wrong with OpenIB?
I think the thinking from Apple on the current configurations is that a dual 2.5Ghz is going to be better than the fastest available Intel-based system with a single 3.xGhz P4. There's no need to make a 4-way box because the 2-way box already beats the best P4 because 2.5+2.5=5. Or something like that. For clusters, who cares how many cores in a single box? Just link a bunch of 2-way systems together.
But, once the G5 goes dual-core, I would expect to see a dual dual-core G5 machine out there somewhere. Does that count?
The fact that IBTA has recently (as in last week) caused a software patent licensing issue for those who wish to implement the spec...