[comp.parallel] NCUBE info sought

weltyc@cs.rpi.edu (Chris Welty) (12/21/90)

We have a line on a cheap 1K NCUBE.  I am soliciting experiences from
current or past NCUBE owners.  Specifically, how much does it cost to
maintain, is it more trouble than it's worth, etc.  Please mail your
comments to me (weltyc@cs.rpi.edu) rather than posting.  Alos, if
anyone knows of a better forum for such a query, I'd apperciate
knowing.  

Thanks.

--

Christopher Welty  ---  Asst. Director, RPI CS Labs | "Porsche:  Fahren in
weltyc@cs.rpi.edu             ...!njin!nyser!weltyc |  seiner schoensten Form"

tve%allspice.Berkeley.EDU@ucbvax.Berkeley.EDU (Thorsten von Eicken) (12/21/90)

In article <12372@hubcap.clemson.edu> you write:
>We have a line on a cheap 1K NCUBE.  I am soliciting experiences from
>current or past NCUBE owners.  Specifically, how much does it cost to
>maintain, is it more trouble than it's worth, etc.  Please mail your
>comments to me (weltyc@cs.rpi.edu) rather than posting.  Alos, if
>anyone knows of a better forum for such a query, I'd apperciate
>knowing.  

Is is an nCUBE/ten or the new nCUBE/2? The latter I doubt, so must be
the former.
I think that if you can do research on 1000 nodes, you're
entering the interesting game, not like people who do research in
massively parallel systems and who show statistics with 32 processors.
However, the old nCUBE was quite unbalanced, in particular floating-point
was slow, which made it a bit too easy to hide the network cost (overlap
the network with a few floting-point ops). At least all this is what I
hear from others having used the machine (I'm using an nCUBE/2).
The point I'm really trying to make here is that you might bias your
research strategy towards this `broken' machine and end up with results
that don't mean anything on a `real' machine. Sorry, can't tell you
'bout maintenance costs...
	- Thorsten (tve@sprite.berkeley.edu)