Slashdot Mirror
Multiprocessor G3/G4 Boards
giminy writes: "These boards from TotalImpact look pretty nifty. Each one can take 4 g3's or 4 g4's and go in a regular PCI slot -- and get this, they can run in Intel machines. They work by having a program dumped to them like a second computer. Still kinda pricey for the cards, but you can put as many of these cards in your server as you want for something super-scalable. Linux support is there, and datasheets are available." We mentioned these back in '98 but a lot has changed since then. I'm sure there are clever uses for a couple of spare CPUs in a box ;)
They're more like "Computing peripherals" - They're PCI cards that fit in any PCI slot. (Well, one conforming to the right specs - One of their 66 MHz/64-bit PCI cards won't work in your average box.)
They cards will not run standalone or as a primary processor, they're slave processors. You still need a host processor, which can be whatever you want. (Intel, SPARC, Alpha, PPC, even StrongARM probably.)
retrorocket.o not found, launch anyway?
If you need to constantly go over the PCI bus for everything (memory, disk, etc) then yes, you'll run out of bandwidth real quick.
However, the board appears to have a lot onboard, meaning that the bandwidth requirements are lower, leaving you with things like a "black box" scenario. You have an image you need manipulated, so you send it to the G4 board with the manipulation instructions. The board gnaws on it for a while without working on the PCI bus, then returns the modified image.
-- Ever notice that fast-burning fuse looks exactly the same as slow-burning fuse? I didn't... (Edgar Montrose)
Here's Motorola's G4 fact sheet. The real lowdown on the G4 is here. Especially check out the hardware spec. (The link seems to be broken or something, though. I looked at it a few weeks ago :(
:( G4s support a range of clock divisors for the external L2 cache SRAMs, from 1:1 to 4:1. Apple uses 2:1 in their towers. (BTW, the cache RAM is external, but the control logic and stuff is all on chip.)
The TotalImpact page doesn't say what speed they run the L2 cache at. (The PDF spec sheet link is broken
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
Looks like they are working on a Linux-specific product too...
Sound is handled by a sound card,
Graphics is handled by a graphics card and now...
processing is handled by a processing card.
Cool.
No kidding. My G3 gets tanked at least twice a week, and cleaning up after it is becoming a freakin' nuisance. Jose Cuervo and coolant paste makes a horrible reek, and don't even get me started on the effects of black coffee on a PowerBook's keyboard...
-----------------------------------------------
All employees must wash hands before seeking equitable relief.
For starters, as others have pointed out, these are slave processors, so by definition, putting this in does not make an SMP box. The S in SMP stands for symmetric, and while the CPU's on the card are symmetric, the card is not symmetric with the main CPU(s).
The way this works is much closer to a mainframe running VM with partitioned systems underneath it. You submit a job by tossing it over the wall to the VM partition (in this case one of these cards) and wait for it to toss the results back. You can probably watch the job some way with a properly written VM subsystem. You probably can't run interactive programs on these cards and if you can, you really wouldn't want to since you would clobber the PCI bus sending keystrokes and screens back and forth. And don't even think about trying to run a GUI on one of these cards.
What these cards are perfect for is batch processing. You write up a queuing mechanism to accept jobs and farm them out to the cards as they become available. The main CPU would manage the UI and the queue. The Cards have their own memory (max 512mb which is not a lot for this type of work) so you can get reasonable performance as long as the data sets are small enough to be loaded into memory on the card.
What this means is that the type of processing you can do with these is limited by the PCI bandwidth and the memory on the card. I don't think this is as great and wonderful as it looks. It's really cool, and if you need to run lots of compute intensive programs with smallish data sets it then this is ideal, but it will choke on high transaction rates and large data environments. Databases are an absolute no-no unless you really hate your PCI bus and want to try and burn it out.
POP is IBM's PPC-based reference platform, which will (we hope!) allow OEMs to build inexpensive and clever PPC-based applications. Design files for the first version of POP never came out due to a bad part (the Northbridge, from Winbond); according to Brad, a "POP2" is on its way.
As always, further info is at http://www.openppc.org.
--Tom Geller
Co-founder, The OpenPPC Project
Tom Geller
As usual, the answer is most likely "It depends." (ObDisc - I don't have one of these cards to play with)
No matter what API you're using (SMP/threads or Beowulf/PVM) these are most likely best used for SIMD (single-instruction, multiple-data) kinds of problems (of which SETI is one). Communication between boards will be a major performance bottleneck, since they all share the same bus.
Since they do have local RAM (and not just cache), you load the card's RAM with one set of code and four sets of data. Do that for all the cards you have. Now wait, and get your answers back off the local RAM. Did you use threads or processes? Threads and its closer to SMP, processes and it is closer to PVM or Beowulf.
But will it outperform a comparable Beowulf cluster? If it is compute-constrained, then the PCI cards will do better, especially as the problem scales, because the PCI cards share hardware costs for disks, network cards, fast bus, large RAM, etc. If it is disk or network limited, though, the Beowulf will eventually win out. The PCI cards will do well on a price/performance basis while the problem is small, because it will still be sharing hardware. But once the PCI bus fills up, those processors will start waiting on the bus. The bigger the problem gets, the more the processors wait. The Beowulf cluster, on the other hand, can distribute all that hardware - instead of one 100Mbps network card, it may have dozens (you start worrying more about what your ethernet switch's backplane looks like).
So these cards are best for compute-intensive simulation-style stuff (image filters would also scream - mostly - FFTs require lots of communication). Simulated wind tunnels or weather phenomena, finite-element analysis, etc.
Note though, that these cards have their own slower PCI bus, including support for an add-on card (!), so conceivably you could get a lot of server oomph by giving every four processors their own network card. But you better make sure you data (i.e., your web site) can fit in the local RAM, or you'll bog down in bus contention again.
-----
Klactovedestene!
Yikes, it just occurred to me that much of the readership wasn't born at this point, but . . .
.m :)
the bus and processor used to run at the same rate. There were many systems in which the processor plugged into the backplane jsut like any other card. S-100, PDP-11 (and others) behaved this way, as well as other lesser known formats. Others took an approach that was similar: the Apple II exposed everything to the bus, and a processor card could flat-out take over. There were a few hybrid systems that used S-100 for expansion, but had a motherboard with a processor and possibly memory.
Then processors started running fasterthan 4mhz . .
If you read the post, it says that these cards will work inside a x86 on binaries that contain PPC binary from a cross compiler...
What would seem sweet...and maybe not to hard to do would be to have some thing capable of running 99.9% of the binaries in existence. While we can run many progs under x86 (WINE, vmware), the PPC will allow us to run LinuxPPC-native and even (if you so desire, but maybe not) MacOS binaries. Now we won't have the ROM (maybe the new-world ROM files will solve this), be we WILL have Darwin to work from for something in a more of a WINE like compatability. If the New-world ROM can be used, it may be possible to get something as complex as mol up on your x86 workstation. Imagine having one workstation where you, the HellDesk employee, could run *NIX ( Lin/BSD, natively), vmware (WinXX), and mol (MacOS 9+) from the same workstation... simoultaneously (ignoring the 512M RAM you'd probably need). In environments that have great OS diversity, this would be great (Universities come to mind).
It would be more beneficial to Mac owners to have the reverse for compatability (putting a PIII or K7 on a PCI in your Mac). There are several companies that do this (and probably have patents) such as OrangeMicro which are anally retaining the hardware specs last I heard. And they only develop drivers for MacOS. Plus I think they require special versions of the OS's that run under the hardware anyway.
You also have the possibility to now section off hardware to a virtual environment (similar to IBM's 390's) because you can easily quantize the resources allocated to each environment by PCI card...
- Sig
PowerPC processors are not well known for their sobriety. Most people willing to add these boards to their servers should seriously think about upgrading their power supplies too, especially if they also use RAID disks or whatever.
BTW, multi-processor, (Strong)ARM-based boards are also being worked upon by companies such as Simtec ; given the average power needs of an ARM processor and the low FPU based needs of a server, this is an interesting alternative (though I am not sure these are out yet).
--
Trolling using another account since 2005.