Slashdot Mirror
Sun Releases Starcat
SilentChris writes: "Sun has released the Starcat server, a beast with up to 106 processors running Unix. Anyone have an extra couple [million] bucks lying around?" They're not cheap.
← Back to Stories (view on slashdot.org)
As someone who does nothing with these types of systems, nor follows them, I think it's great that you can have different processor speeds using "partitions."
I wonder if memory is treated the same way... i.e., separated by "partitions," or if you also have a choice to use it as one, large unified memory resource... or, I wonder if memory can be dynamically partitioned... hmm.
Actually, now that I'm thinking about it... are all of the processor partitions considered peers? I mean, are the partitions all treated as if they were a single processor... then treated equally?
to get on the National US ID Card database bandwagon with Oracle... It'll only need to store about 300 million records with DNA, fingerprint, picture for facial recognition software, key escrow, etc...
try { do() || do_not(); } catch (JediException err) { yoda(err); }
"Huh? I understand that the nation's air traffic controllers may need updated equipment in light of the existing crisis, but how hard can scheduling be? I could see a use for a massively parallel monster like this in, say, flow-through or structural analysis or something, but scheduling? "
What your missing is that this isn't a matter of airtraffic control. This is a matter of determining which planes and crews to fly to which locations at what times to maximize revenue. This is a classic, big, nasty travelling salesman problem. The bigger of a beast of a machine you get, the closer you get to an optimized solution. I.E. Most passengers willing to pay this most money with the least use of resources. It's a huge problem that needs massive computational power.
Just wait for six months. This is the first beast in a series of pseudo-clustered Sunfires. This is roughly a stack of 6800's, and there's going to be a MUCH larger machine released very soon.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Yes, there's a buy online button. But that's used to get info so one of their sales droids can contact you. It's not like you can slap it on your Visa card. :)
(Disclaimer, I work a lot with E10Ks, so this post is written mostly from my experience with those.)
The 15K is basically just an improvement on the E10K architecture, from what I've seen and heard from Sun's SSEs. The E10K started out life as the Cray SuperServer, and was sold to Sun for a song. It's not architecturally perfect. The E10K is set up to allow individual system boards to be part of domains (aka partitions), which can make for some great scalability in the domains. I've seen tiny little one-system-board domains, and domains with 13 fully populated system boards in them.
One of the major advantages to this platform is the fact that you can hot-swap everything except the centerplane. (Of course, I've never seen a centerplane fail.) The E10K also has Dynamic Reconfiguration, where you can remove system boards from a running domain, but unless your platform is set up in a certain, specific way, this doesn't work as well as advertised. I've personally never used it. The best thing about the E10K is the use of the System Service Processor, which handles all the administrative tasks for the entire cabinet. I've heard that the SSP is now integrated into the 15K, thus eliminating the need for a separate system to perform these tasks and monitoring.
The only thing I've ever seen this class of system used for is data warehousing. No modeling, no graphics rendering, just Oracle databases. Just because it has a large number of processors, doesn't mean they're going to be suitable for every task imaginable. (I used to have a 180MHz Indy R5000, that got 68kkeys/sec in d.net. My 166MMX got something like 350kkeys/sec.) These are workhorse processors, not sports-car style processors.
Though I wonder if Sun's gotten around to fixing that nasty ecache parity error problem with their processors... Having a domain randomly crash because the parity bit on a processor got flipped is no fun when you're dealing with a large production database. I have a feeling that problem will continue to plague them in the 15K.
A good traveller has no fixed plans and is not intent on arriving.