Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!hubcap!tve%allspice.Berkeley.EDU
From: tve%allspice.Berkeley.EDU@ucbvax.Berkeley.EDU (Thorsten von Eicken)
Newsgroups: comp.parallel
Subject: Re: NCUBE info sought
Message-ID: <12383@hubcap.clemson.edu>
Date: 21 Dec 90 15:15:02 GMT
References: <12372@hubcap.clemson.edu>
Sender: fpst@hubcap.clemson.edu
Reply-To: tve%allspice.Berkeley.EDU@ucbvax.Berkeley.EDU (Thorsten von Eicken)
Organization: University of California, Berkeley
Lines: 22
Approved: parallel@hubcap.clemson.edu

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)