posted 05-02-2001 17:33            

Beowolf Cluster
Recently I've been on a Beowolf Cluster kick, reading, researching and planning out how we could round up the parts for this cluster but we wouldn't really have a need for a cluster, we could render things in Povray or compile massive things but other than that I can't think of any practical pen usage beyond just doing it for the experience. And of course you'd be able to access it on penTernet. So come on folks give us a reason to build one, I'm just itching to start in.. If you don't know what a Beowolf Cluster is, think Home made super computer using many computers and distributive processing tactics.

Of Course I doubt we could top these people building a Beowolf cluster out of Furbys
Submersible Cooling Solution
Oh how we love to overclock, since we can be some cheap bastards we do enjoy getting the
most bang for the buck. We've been kicking around the idea of how to build a stable and
original submersible cpu setup. Many people have run and overclocked machines that are
submerged in mineral oil or fluorinert (ala Cray super computers) but for the exception of the Cray setups, nobody has really setup a stable submersible machine that tickles my fancy.

Last night at the bar Weis bounced some sort of Merry Go Round submersible idea off me. I was really to drunk to actually remember the details but maybe if you are all good kids, he'll post up his plan here.

So lets here your vote on what new project we should take on. Got a suggestion for a project? Lets here it.

posted 05-02-2001 19:49            

-Seti or some other distributed thingy?
-A "vague post by Cyd" -generator?
-A fully automated "sign Jimb0 up for every mailing list known to man" -machine?

Enlighten me. I doubt you want to use it to predict the movement of air molecules over that new revolutionary wing-structure you told me about.

posted 05-02-2001 20:06           

Oh yeah. Nowhere. Crap. But it'd be cool if that worked... water has an awful lot of heat capacity.

Right. Keep in mind I told you I didn't know anything. You were warned dammit.

posted 05-02-2001 21:44            

another idea for the comp cooling is to use dry ice, i have seen this before, where there is a ocmpartment fo dry ice and it has a fan sucking off of it, down a tube into the area to be cooled while above each board there are outgoing fans.

submerged system, use an old fishtank and then a plastic case, seal it completely first, then modify by taking tubing and plexiglass and making ducts and channels through the housing itself where nothing alse would go, put everything in it, put the pc onto the bottom of the tank, and put in water and a cooling system for the water (they sell them at special pet shops for cold water fish,
that way you have a fish tank that has a computer in it where fish can swim through the tank.

posted 05-02-2001 23:51            

What you really need is a dual-pump setup - one intake pump, one exhaust pump - and intake/exhaust lines that, instead of ending in a simple round hole at the end, branch out into a sort of capillary system.

    /=
--/==
 <===
--\==
    \=

Hopefully that gets across the idea of what I mean by a "capillary setup" for the ends of the intake and exhaust lines... the idea is to maximize the area of coolant flow, rather than creating one single "flow pipe" through the center of the tank.

At any rate, you put the intake and the exhaust at opposite ends of the tank, so as to create a steady flow across the entire tank, cooling all components.

The second tank, which is used strictly for cooling, is nothing but a great big set of heat-conducting vanes - no rotating required - which the coolant flows constantly through and across. You can put peltiers - if necessary - ABOVE this secondary coolant tank, again obviating the need for complex fluid-tight fittings. (In addition, of course, heat DOES rise after all. Need I say more?)

It's gonna be a hell of a lot easier to rig up a couple of aquarium pumps and some line between two tanks than it is to try to create a big whirligig in the same tank with your electronics.

You could, of course, just set up the cooling devices in the same tank with your electronics and still pump coolant across them - but I think it would be a much better solution overall if you had separate tanks for the cooling and the electronics; you could probably get better heat transfer distribution on both ends that way.

posted 05-02-2001 23:57            

While I'm on the subject, time for a rant.... There's no damn reason to run something on a beowulf or even on a dual-proc machine unless it takes advantage of the multiple procs or nodes. If you played halflife on a 64-node beowulf monster, it would be identical to playing it on a single one of those nodes, because it doesn't know how to utilize the others. Similarly, I hear people bitch about how SETI doesn't have SMP (dual-proc) or beowulf support; the answer is, because SMP-empowered SETI on dual-proc would run at best at the same rate as two instances of regular-SETI on the same box... most applications don't even lend themselves to the idea of clustering. Furthermore, if you tried something SMP-specialized but not built for a beowulf, it would probably run slower on a beowulf, because it would do such a shitty job on memory (and still only use 2 or 4 procs). So, maybe someday in the future, clustering will be commonplace; but for right now, if you're actually using a beowulf to its full extent, odds are near perfect that you had to custom-write the code.

posted 05-03-2001 01:19         

edit: and i know there's ut.

posted 05-03-2001 01:56            

And I think that well get more and more applications that make us of SMP systems as we push proccessors smaller, faster and hotter. (ha. i'm sure you all knew that. i just felt like saying it!)

posted 05-03-2001 09:55            

We're definitely beginning to approach the limits of what can be done with making single processors faster - not that I'm saying we're there yet, mind you, but it's becoming very obvious that it's happening. Just compare the heat transfer problems of today's 1GHz machines with the 8-bit era and you'll see what I'm talking about!

At any rate, as we approach the limits of what we can do to make a single processor faster, we will begin experimenting more and more in the mainstream with unloading threads to individual processors. Think of it kinda like how much RAM you have - you can still get a job done if it requires more RAM than you physically have available, but you have to use "virtual memory" swapped in and out of your hard drive.

Our current "multitasking" is largely similar - really, we can't execute but one thread at a time, but our "virtually multitasking" systems assign threads timeslices on the CPU and load and unload different concurrent tasks on a schedule.

posted 05-03-2001 14:01         

on top of that, why should they spend the effort when the majority of people won't actually see any improvement over their uniproc machines? multiprocessing is really only necessary for heavy scientific calculation and about the only application of that for consumers is 3d games. a giant performance boost in quake might sound nice, but is it worth the amount of r&d to get it out of the box and working as a standard api?

posted 05-03-2001 14:23            

I thought we had that debate

posted 05-03-2001 16:52            

quote:

---

Originally posted by deeznuts:
look at how long ms took to bring in virtual memory

---

Since Windows 3.1 or so? Maybe earlier?

quote:

---

on top of that, why should they spend the effort when the majority of people won't actually see any improvement over their uniproc machines?

---

I beg to differ. In the process of running Winamp, Excel, Outlook Express, AIM, and one window of IE5, I'm currently using ::checks quickly:: 292 threads on this machine.

SMP doesn't help for a lot of applications currently because support for it isn't all that robust - unless the APPLICATION supports multi-threading over multiple CPUs, all an application's threads run on the same CPU. What I'm telling you is, THAT IS GOING TO CHANGE.

Maybe you don't remember the 8-bit days, but I do. Back then, you didn't even have a memory manager - EVERYTHING was bare metal. Applications used hard addresses to refer to data in RAM rather than running through a manager, and you generally couldn't have two different apps in memory at once - whether or not you actually attempted to multitask - because they'd try to both jump on the same segment of RAM.

Then MS-DOS came out, and while it was really a bit much overhead at first, it was the wave of the future - systems got fast enough in hardware to cope with the added overhead of running memory access through a manager rather than running to the bare metal, and the flexibility this allowed programmers made it an absolute necessity.

Later, add virtual memory to the game.

After THAT, add virtual multitasking - the assignation of timeslices to a processor.

Yes, I'm betting that before too much longer the trend IS going to continue with management of thread assignation to a particular CPU becoming a function of the OS, so that app developers don't have to worry about it any more than they have to worry about exactly what addresses in RAM their app physically loads in anymore.

This will allow multiprocessing to become a LOT more useful and expansible - and again, I repeat, a rather light workload currently has me running TWO HUNDRED AND NINETY-TWO THREADS. If you don't think a well managed multiprocessor setup would result in better overall system performance, you're nuts.

Again I repeat, CURRENT SMP IS NOT WELL-MANAGED. Current SMP is a fucking kludge. But this, too shall pass... look forward to OS-based multiprocessor management, 'cause it's definitely gonna happen.

posted 05-03-2001 17:39         

1) are you seeing any really noticeable slowdown? while that may be a light workload for you, it seems about normal for most computer users. and if it's running all that with no slowdown, what's the point in speeding it up?
2) most of those 292 threads are blocked at any given time. allocating them to different processors would leave them sitting dead on a second processor.

point 2 brings up the reason multiprocessing takes so much extra programming now. a lot of the research would go just into figuring out how to allocate processes to each cpu when you don't know if a process will actually be running most of the time and what processes will be queued up on each cpu in the future. having a dozen extra processors won't do you any good if all your active threads are sitting on one processor. as you add more and more processors you lower the chances of that happening by sheer brute force, but like i said that will require a lot of hardware and that won't come cheap.

i don't disagree that multiprocessing will become more common, but at least in the 10-20 year range i think it'll be quads at most not 16-64 proc monsters in every garage. focus will probably turn to wearable models, progressing from the pda craze that's been going around lately. mostly for doing goof ass things like checking email on your sunglasses and temp regulated clothes. sure that fucks with the current chipmakers' plans as much as cheap and ubiquitous mp, but only if it caused the current market to dry up. i figure these devices will be cheap enough and of a narrow enough purpose that it won't cause any massive shift, just open up a new market.

unlike multiprocessing, wearable hardware doesn't have an established oligarchy yet. also, this new tack wouldn't really cut into business for the old style of computing since the wearable devices would be less general purpose (at least at first). so new companies could rise up or the old players could move in for a new revenue source, instead of disrupting the financial plans of large and powerful companies - which does not bode well for any technology (or we'd be driving electric cars right now).

posted 05-03-2001 23:53            

The argument "what slowdowns do you see now?" is simply retarded - the same argument would apply equally well to "why make faster processors at all?"

And incidentally, multiprocessing hardware CAN be cheaper - most modern consoles are multiprocessor, with separate CPUs devoted entirely to video, audio, math/logic, etc. Quite simply, using less powerful overall CPUs to offload tasks to makes the product more robust and less prone to overheating... and last time I checked, even a PSX2 was considerably cheaper than even an entry-level PC.

Anyway, we'll find out in ten or twenty years who's right on this one... but remember, the president of IBM went on record as saying "I see no reason why anyone would ever want a computer in their home", and one of Bill Gates' most infamous quotes is the old "640K should be enough for anybody."

Every generation of software both does more and requires more resources. This will not change. People want machines that don't require special refrigerated rooms like old Honeywell mainframes. The faster CPUs get, the more heat they generate.

posted 05-04-2001 09:58         

massive parallelism for the masses is another story though. it means opening up a whole new area of r&d for a feature that won't improve the computing experience for very many people. it will still have academic support since advances in multiprocessing would be a boon for the scientific community, but big time corporate money will be spent on something they can sell to a lot of people.

like i already said, tech industry research will probably go towards getting a computer in every home and a half dozen strapped onto everyone. computers are already complex enough to scare people, the challenge for companies now is to make them as cuddly and non-threatening as the average toaster. not in the fun flavors sense of an imac sense(although you'll be seeing more of that, it's more marketing than research anyway) but in the sense that you won't even realize that you're interfacing with a computer at all. that means getting them small, completely reliable, and intuitive - three things that have taken a back seat to raw power thus far.

besides slow results dripping in from academic research there will also be specialized uses of multiprocessing. take video cards for instance. i've seen press releases for 64 parallel processor video cards, but that's with a known and easily parallelizable process. it doesn't translate as easily to general computing. besides which the technology has been around since the mid-80's thanks to sgi and is just now making it to home use.

massive parallelism is indeed coming to the average consumer, but 10 years and maybe even 20 is just being blindly optimistic.

edit: and about coprocessors - they are just that: coprocessors. besides game consoles, computers themselves have been using coprocessors for about as long as i can remember. your computer right now probably has a video accelerator, a sound card... hell even the modem probably has a microcontroller integrated. that's not the same as actually offloading arbitrary threads. the fact that they are dedicated to a single task makes them just as much a cheesey hack as the current smp. when your sound blaster starts doing video rendering then we can talk about it being a real parallel processor.

edit again: and the psx2 is cheaper than a computer because sony sells it at a loss, not because of any genius design moves. the actual cost to produce is roughly the same as a pc.

[This message has been edited by deeznuts (edited 05-04-2001).]

posted 05-04-2001 15:17            

quote:

---

the actual cost to produce is roughly the same as a pc.

---

...But aren't most PC's hideously over-priced?

...and... since the PSX2 is dedicated to NOTHING but gaming... shouldn't it be a *little* cheaper? (I dont feel like researching right now)