Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Silicon Graphics

SGI Installs First Itanium Cluster At OSC 198

Troy Baer writes: "SGI and the Ohio Supercomputer Center (OSC) have announced the installation of the first cluster using Itanium processors. The system consists of 73 SGI 750 nodes, each with two Itanium 733MHz procs and 4GB of memory, connected by Myrinet 2000 and Ethernet. Software includes Linux/ia64, SGI's ia64 compiler suite, MPICH/ch_gm, OpenPBS, and Maui Scheduler."
This discussion has been archived. No new comments can be posted.

SGI Installs First Itanium Cluster At OSC

Comments Filter:
  • Yes, that is spelled as desired you fools. Apple has struggled with this issue - what chance is there that Intel/PC manufacturers will do any better?

    Of course Intel has the big advantage that if person X doesn't go for 733 Mhz Itanium or even y * 733 Mhz Itaniums, they'll still go for 1.8 GHz Intel P4. I.e. they don't have to sell the Itanium to consumers yet, whereas Apple has to sell the PowerPC. I.e. Intel, like Microsoft, can win by stagnation.

  • hread&order=0 [] :Information about the cluster itself and the nodes
  • Seti@home (Score:2, Funny)

    by goonies ( 227194 )
    I bet they only want to beat the sith out of the top10 seti@home users by sending in packages every 10 minutes.... ;-)
  • "Software includes Linux/ia64, SGI's ia64 compiler suite, MPICH/ch_gm, OpenPBS, and Maui Scheduler."

    One only wonders if this would be posted on Slashdot if the OS was Microsoft Windows 2000 Datacenter. :) Just a thought...

    • Re:Interesting (Score:3, Informative)

      by Guppy06 ( 410832 )
      "One only wonders if this would be posted on Slashdot if the OS was Microsoft Windows 2000 Datacenter."

      It wouldn't be worth mentioning, since you can't cluster more than four nodes with W2k Datacenter. When you compare that to this cluster of 70+...

  • by Anonymous Coward
    Troy, How much power and A/C is required to run this 146 Itanium processor cluster? I have heard that 1 itanium node uses two 800 Watt power supplies and generates 6174 BTUs/Hr. I am guessing that you required 116.8 KiloWatts of power and 37.5 Tons of A/C. Please correct me if I am wrong. What did you have to do at your site to support this cluster?
    • OSC's Itanium cluster is physically located at the State of Ohio Computing Center (SOCC), which provides all the power and cooling. The power for the cluster is nineteen 30A/220V circuits, which go to a set of Sentry power controllers. The total heat load is about 195k BTU/hr, but the SOCC building is (over-)engineered such that this much of a heat load did not require additional AC capacity.

  • by green pizza ( 159161 ) on Friday August 10, 2001 @04:54AM (#2117578) Homepage
    Slashdot is *still* using the old cube logo, rather than the new "sgi" logo. Sure the new logo sucks and the old logo is quite cool, but it's time to move on. The old days are long gone. Like the rest of the 'new' SGI, there is nothing special about the SGI 750 Itanium box, it's the same box with the same Intel reference board that HP, Dell, and others are selling.

    SiliconGraphics has left the building. The "hip new" SGI is here. Quit using the old logo, it reflects a much cooler company that no longer exists.
    • Hey, never give up hope! Remember how Borland changed their name to the laughable "Inprise" some time ago? They're back as Borland now. Companies want to please their customers, and if enough want some part of the old SGI back they'll get it.
    • Has anyone else noticed a little bit of a turn in SGI's marketing of late? For a while all I saw advertised was the new Intel cruft, but recently I've been seeing a lot more ads for Octane2s and O2s. Not only that, but they call them Silicon Graphics workstations.

      I think SGI has realized the folly of its full-scale leap into Intel and is finally starting to get back to their roots again.

    • by InsaneGeek ( 175763 ) <slashdot@insanege[ ].com ['eks' in gap]> on Friday August 10, 2001 @07:54AM (#2156855) Homepage
      Would you consider the following link new & cool??? wn load/mips128.out

      It's a link to a running *single image* (i.e. not a beowulf cluster) 128 proc Linux system on a mips box. When was the last time you saw Dell, HP, Gateway, do that with a Linux system? This little cluster in the post is not where SGI is going with their systems (as you said anybody can do that) but are moving with Intel numa with high speed numalink interconnects that are much faster than standard Myranet (their cross bar is in the gigaBYTES).

      The real interesting part that I see (if they can live long enough for Intel to release Mercede) is the system partitioning and it's modularization. Need 2 more procs for your database but all your CPU slots are full, well plug in another "C brick", you won't have to worry about running out of CPU slots in your frame, everything is a component, you won't have to do another fork lift upgrade. Also with their partitioning I can purchase a 100 proc system, partition it into twenty 5 proc systems all within the same frame I don't have to pay for all of the overhead for 20 different frames and space for expansion in 20 of those frames, because all I need to do is plug in another "C brick" and give two of the boxes two more CPU's without ever having to have bought the headroom to begin with.

      Whoa getting a bit long, SGI really has some cool stuff going on right now. If they could only market themselves out of a paper bag they wouldn't be in the bled-dry situation they are in. Personally I think the best thing for them would be to be bought by someone with big pockets who can market a product properly.
      • I think you're making partitioning sound easier than it actually is. IIRC, for each partition, you need a seperate I-brick. They're _not_ cheap. It's much more cost effective to go with a large, single-image system.


        • In my example you have already purchased the I-brick, possibly the R-brick (depending upon how large you are), if you are using XIO the X-brick, etc. All you are doing is adding some more CPU's to existing systems in the 3000. Which before if I had 32 procs in a Sun 6500, you were done you had to do essentially throw our your 6400 and do a forklift upgrade to an E10k; with SGI's 3000 you are at CPU's you don't run out of headroom, you never have to get rid of your original investment. I can start with a 4 proc system and scale it up to a 1000 proc system and never have to throw out hardware to get there because you don't run out of headroom (there is a theoretical max I will admit but it's a limitation in interconnect speed).

          Anyway yeah, you have to buy the I-brick, P-brick & C-brick to get a system running and each system will need to have at least an I & P brick; but to add to an existing system no problems.

          • Err, actually, you won't need a P brick unless you need more than 5 PCI cards. One of the features we are kicking around (read "maybe someday we'll do this but don't go telling anyone that we're committed to it") for system partitioning is the ability to boot a partition I/O less from another partition. You would then be able to NFS mount a root file system over the cross partition communication layer (network interface "cl0").
  • by Perdo ( 151843 ) on Friday August 10, 2001 @05:31AM (#2118096) Homepage Journal
    5.86 Gflops per processor (We can assume marketing fud value) at $3,300 Compared to the Athlon 1.4 with a peak of 1.37 Gflops (benched value) for $145. Keep in mind the nifty PCI card that has 4 G4 processors on it. That would make for 92 processors at 1Gflop each in just one box.

    Unfortunately, this seems to mark Intel's latest attempt to push an overpriced, substandard product at us. The P4 was crippled from the begining and is only just now begining to show any promise. The PIII at 1.13 and 1.2 Ghz is finally available 8 months after the recall of their failed 1.13 processor. Even their purchase of Alpha from compaq seems to be just stock propping because the original creators of the alpha are now working for AMD. The reason Compaq was willing to sell in the first place is the second generation alpha has been subjected to over three years of delays because they simply did not have the engineering talent to improve a ten year old design.

    The talented engineeers are working for AMD, built the athlon and are working on the sledgehammer.

    Before anyone jumps to Intel's defence, like they need defending as long as they are the 800 pound gorilla, keep this in mind:

    Craig Barret warned "This was a year of record annual revenue and earnings; yet, slowing economic conditions impacted fourth quarter growth and are causing near-termuncertainty,". He was faced with AMD going from 10% market share to 34% market share in a year. Wall street took barret's word as gospel that the entire market was in decline and not just Intel's market share. Intel is a market bellwether so we all got laid off. Just so Intel would not have to admit that AMD had a better product. Nasty business. Intel does not have a great product and they are reckless with their power.

    • by Anonymous Coward
      think again, Apple current top-end dual 800Mhz PowerMac G4 runs AltiVec code at over 5GFLOPS. My older dual 450Mhz can run up to 3.2GFLOPS... And don't forget, the G4 has a successor due pretty soon now. I think these guys will find the pleasure of being the first will be tempered by eventually having the worst price/performance 64bit cluster in academia.
  • by Anonymous Coward
    True HPC Coder:
    Myrinet interfaced via PCI? Argh! SN-IA won't be here soon enough!

    l33t d00d with an overclocked athlon:
    SCHWEEEET, a BEOWULF CLUSTER! With an IDE RAID on each node I could have years of DiVX movies on that!!!
  • Can anyone imagine a Beowulf cluster of "Where is the old SGI " laments ?
  • by HerrGlock ( 141750 ) on Friday August 10, 2001 @07:03AM (#2123340) Homepage
    It seems the ones who have been faithful to their commitment to Linux are SGI and IBM. The others have tried it and then decided it was not worth the effort to reach such a small segment of the population.

    I'm glad there are still big players in the Linux field, though, it helps forward the cause and the OS and lets people know there IS an alternative. By all means, SUN and other, keep your propriatary stuff available and have that as the default, but allow people the option to choose another OS if they so desire.

  • Slashdot (Score:2, Insightful)

    by Anonymous Coward
    This story: _s upercomputer_dc_1.html

    Has been out for all most *five* hours. The story talks about how Linux is going to be used as the OS for the *biggest* *cluster* *of* *super* *computers* *in* *history*

    It is the greatest news I have heard in months and it "matters" if you ask me. The Super computer(s) will be funded by the National Science Foundation(NSF) and it is reported that the super computer(s) will be able to calculate in one second, what it would take a hand calculator ten millions years to calculate. In addition the total disk space will be enough to hold all most one and a half million full-length novels.

    In other words, the Linux OS is going to be used for the largest computing grid in the history of the world.

    This story has been availavle on Yahoo!(TM) LinuxToday, Newsforge etc for hours. I submitted the story 3 hours ago and nothing...

    I used to read slashdot for the news and told myself I could ignore the mindless trolling and moronic comments, now I realize the news service is garbage and I have no reason to read /. anymore.

    Looks like it is newsforge or LinuxToday for me
    • The story has been out for months and people obviously haven't been paying attention or at least have failed to see just how concerted this effort is. This technology isn't new, but it's just a small part of the whole if you know where to look.

      The new systems sound great, but they're tiny compared to what it's going to be like when the GRID is up and running.

      What the story fails to mention is that this system is likely to be connected to the other GRID environments in the States and the new ones in Europe at which stage you wont be talking about just 4 super computer centres but nearly a hundred, each with several Tflops of processing power and a few petabytes (10**15) of storage.

      I would suggest that to put this in the proper perspective you also look at IBM's contract to do the same to 4 sites in the Netherlands, the UK GRID which has 9 sites, the German one which I dont know much about but is fairly advanced and the CERN DataGrid. These are all interconnected with the same people working on several at a time.

      Or you could have a look at the top500, find all the supercomputers in Europe & the US which aren't classified or commercial and then figure out what their combined processing power is. You should then have a fair idea just how much processing power there will be in a couple of years time 8)

      Now back to the Particle Physics experiments ...

    • We can ask it for the answer to the great question of the universe?
    • Re:Slashdot (Score:2, Insightful)

      by kietscia ( 149772 )
      A whole 5 hours before it showed up on Slashdot.
      Oh the humanity . If I'd only known about this a few hours ago when that extra $10M laying around on my boss' floor I could of had one. Impatient twirp went and spent the whole wad on 1 month of 24x7 support for our lone Win2K server.

      Reading /. is not done for timeliness (although I usually see things here first) its for the breadth and variety of articles. If you want a place where things show up picoseconds after they hit the ether then you've shown up for the wrong party. And yes, there are trolls and moronic comments (scroll up a bit and you might see one) but the good stuff far outweighs the negatives. Since I gave up coffee (I'm still in mourning over that one), /. is the first thing I do in the morning.
  • IA64s are kickass... (Score:5, Interesting)

    by Telek ( 410366 ) on Friday August 10, 2001 @04:19AM (#2124106) Homepage
    I had an opportunity to work on them about a year ago (the first one we received was a doorstop, literally... The sucker weighed 73 pounds in it's shipping package (I'm NOT KIDDING... They reeled the box in on a trolly, and I laughed at the guy cuz it looked small enough to carry, but then I tried to pick it up...) and didn't even boot, but intel shiped them with 2GB of ram and a kickass SCSI system, so let's just say that my desktop became a SWEEEEEET machine.), but once we got ones that did work, they were sweet machines. I was porting bigint libraries for encryption that I had hand-coded in assembly for the x86 platform, and going from 8 general purpose registers with 1 predicate register (i.e. only 1 carry flag) to having 128 general purpose registers, and 63 predicate registers was a GODSENT.. AMAZING... For anyone who's coded math routines in assembly, you know how much of a PITA it is having only one carry register. This was simply amazing. I could do 1024-bit RSA purely in registers, no memory access outside of the initial read of the data and the final write. Needless to say it flew. It was interesting because literally you wouldn't need a hardware crypto card if you have an Itanium system. So basically Intel really put in a lot of good effort into designing this new platform to avoid the pitfalls of the problems that they experienced with their x86 architechture.

    The machines also had 4GB of ram, so it was fun to do:

    char * myStr = (char *)malloc(-1);

    and have it succeed! (that's a 4GB memory allocation)
    • imprecise exceptions

      IA64 has pretty clean and easy asm, but debugging is a complete nightmare. It's certainly better than x86, but give me MIPS64 or MIPS R1X000 any day.
      • imprecise exceptions

        That's kind of a pain (and at least the IA64 can be forced to do percise exceptions). Debugging something that the compiler has software pipelined will be a giant pain. Your source code will look like a simple loop, but the machine state will show you in the several times (i=7, 8, 9, 10 all at once...but not quite as far into the loop for some values).

    • Why is the parameter to malloc only 32 bit? This is a 64 bit architecture, you should be able to allocate more than 4GB.
      • because I was using base standard c calls at the time, which use 32-bit params. I was just futzing around trying to see how fast I could access things, etc, and porting some code that already used malloc, so I said "hmm, I wonder" and tried it with malloc(-1). Fun!
    • Hm, I don't think ia64 was ever designed to be programed in plain asm. Isn't it very painful to care about that epic stuff by hand?
    • by schwap ( 191462 )
      With that many registers, wouldn't it be better to let the compiler do the work since it should be able to optimize it quite well? Being an assembler programmer at heart, I know the necessity of getting down to the bare metal, but my experience was that I only needed to do it because the x86 arch had so few registers that I could, indeed, do it better than any compiler.
      • It's not only a matter of optimizing for using fewer registers. If you're coding loops for instance, you would most likely want to use the register rotation stuff to do software pipelining of your loop: register r32 becomes r33 from one iteration to the next, register r33 becomes r34, and so on (same thing for predicate and floating point registers). Using this technique you can do some really kick ass optimization of your inner loops. Only problem is that coding the thing and debugging it will do your head in. Now, you would want the compiler to do this stuff for you, but gcc does not support it yet (the SGI Pro64 compiler does, though).

        This was one example of low level optimizations, another one is giving hints to different branches (both target and outcome of branch conditions). This is also best done by the compiler (at least the branch target hints), and works even better if you can supply the compiler with profiling information. You can also give data prefetch hints and specify which cache level different prefetch data should go into.

        Another example of when you might need to do asm is when you do SMP. The reason being that different load and store instructions are given semantics of how the are to behave in a multiprocessor environment: you want acuire semantics on this load, release semantics on this store, fence semantics here, undefined semantics there, etc. I can't see how the compiler would be able to generate correct assembly in this case (unless it is modified so that you can attach some new attributes to your variables and types).

        Then there is this whole plethora of floating point stuff that I won't mention because I don't know shit about it.

        Hmm, reading your post again I see that I didn't really answer your question, and most of my ranting about doing asm coding ended up with the conclusion that having the compiler do all the nasty stuff is probably better anyway. I guess I'd better shut up now.

        • I haven't done work on the IA64 yet, but I have done work with a software pipelined DSP, the TI TMS320C6701. I found out the following things about compilers for such beasts:

          1) The compilers are MUCH more complex and therefore have complex bugs when compiling complex loops
          2) C/C++ are not good enough languages to express enough hints to the compiler to allow it to optimize properly.
          3) Therefore, C/C++ require non-portable language extensions for these hints.
          4) Advanced usage of C++ inline templates CAN help, but are still not as flexible as you want in terms of allowing the best re-ordering of code possible.

          For example, you HAVE to use the new 'restrict' keyword to give the compiler hints about un-aliased pointers. pragmas or similiar hacks are required to give the compiler hints about how many times a loop will be executed - for example, telling the compiler that although a loop is repeated based on a separate run-time variable or parameter, it is guaranteed to never be 0 and will always be a multiple of 8 loops. That kind of thing allows the compiler to really do a good job on the loops - but is not part of the C/C++ standards.

          In my opinion, C and C++ are too 'low level' and restrictive in terms of allowing the compiler to re-order the code to be really effective on non-typical architectures like these. Unfortunately there doesn't seem to be any other options. I would expect that a functional language like OCaml would allow the compiler much more freedom to do a better job - Once there is real support in OCaml for the ia64....

          Also, I highly doubt that GCC is going to be the best or even a very good compiler for ia64 for some time. I'll be happy if i'm wrong though!

          My opinion is that you did the right thing by diving into the assembly.

          • ***EXACTLY*** my point....

            C is very very limited... For example, the single most important thing when coding math is using the carry flag, and there is NO WAY to use the carry flag in C... For example, to add 2 32-bit values together in C:

            boolean add32 ( UINT32 a, UINT32 b, UINT32 &res)
            *res = a + b;
            return ( *res > a );

            whereas in assembly, you can just use the flag... This results in **at least** twice the speed of your application, just for adds... C is way too inspecific to be used effectively for math routines. That's why I had to resort to assembler. Even on the kickass IA64 with wacky crazy assembler that's very very wierd to use, and we are told by intel that "you should never need to use assembler, we have spent millions of dollars optimizing our compilers for it!", they specifically instructed us to NOT USE ASSEMBLER in our ports of our crypto code, citing that it'd be faster to use C... Well I did that, and then later on ported it to assembler myself, by hand, and showed them that the asm code was 3x faster than the C code... Why? Just because of the things that I could access in ASM that I couldn't access in C. The people at intel were not too happy about this, and couldn't understand why it'd be faster. (sigh). Oh well... (end rant)
    • You may want to look up the word "Literally" in the dictionary.
    • The machines also had 4GB of ram, so it was fun to do: char * myStr = (char *)malloc(-1);

      You're going back to school, m'laddo.

      malloc(3) has overhead. You should have expected that to fail if you were thinking only of how much RAM you had. Fortunately, modren cowmpooterz has virtual memory. So you could have got away with that when you got your first 5GB hard drive.

      • Are you new to computers? The memory you get from malloc isn't actually allocated until you access it. There is no translation for the pages at first, so the first access gets a page fault at which point the OS maps a PTE to it. And, no, you could not achieve that with your first 5GB hard drive because most likely you were running IA-32 which supports only 32 bit linear addresses. On Linux a process has a maximum of 3GB of memory so that's the maximum you would be able to allocate (subtracting the tiny overhead from malloc, as well as the other code and data the process has).
        • "The memory you get from malloc isn't actually allocated until you access it."

          malloc(3) has a job to do, and that's to keep you from using memory you can't use. If it doesn't "allocate" it until you access it, then whatever system you're using is incontrovertibly broken.

          malloc(3) is at least two layers above the actual memory. Plenty of room for the MMS and MMU to translate it.

          Don't go assuming what I was running.

          And if Linux limits memory to 3GB (which I did not know, as I don't often dig around the internals of toy computers) then what good is it?

  • Humm (Score:1, Funny)

    by Aqua OS X ( 458522 )
    Intel... you're painting yourself into a corner with this mhz battle against AMD, Moto, and IBM.
  • in related news (Score:3, Informative)

    by Matthew Luckie ( 173043 ) on Friday August 10, 2001 @04:28AM (#2124116)
    there is a much larger cluster of linux machines going to be created care of the NSF. press release here []. good day for linux!
    • "The DTF will be the largest, most comprehensive infrastructure ever deployed for scientific research"

      "creating the 13.6-teraflops system--the most powerful distributed computing system ever"

      OK, what exactly does that make seti@home? 16.98 TeraFLOPs/sec as I write this, distributed computing system, scientific research... What am I missing?

  • this reminds me of the cluster here at my university.
    a team of about 4-5 guys trying to keep the network up and running because of stupid users.

    let's just hope this megacluster will be put to good use and not be the target of some bored hacker who installs a counter-strike server or whatever.

    *believes in the good of humanity*
  • a dialogue (Score:4, Funny)

    by the_tsi ( 19767 ) on Friday August 10, 2001 @09:10AM (#2124639)
    Slashdotter: I wish to complain about
    this company what I read about not half an
    hour ago on this very website.
    Me: Oh yes, the, uh, the Workstation manufacturer...What's,uh...What's
    wrong with it?
    S: I'll tell you what's wrong with it, my lad. it's dead,
    that's what's wrong with it!
    M: No, no, it's uh,'s resting.
    S: Look, matey, I know a dead company when I see one, and
    I'm looking at one right now.
    M: No no it's not dead, it's, it's restin'! Remarkable company,
    the SGI, idn'it, ay? Powerfull CPUs!
    S: The CPUs don't enter into it. It's stone dead.
    M: Nononono, no, no! It's resting!
    S: All right then, if he's restin', I'll wake him up!
    'Ello, Mister Bob Bishop! I've got a lovely fresh government
    contract for you if you show...
    M: There, it moved!
    S: No, it didn't, that was you faking a press release!
    M: I never!!
    S: Yes, you did!
    M: I never, never did anything...
    S: (yelling and hitting the cage repeatedly) 'ELLO SGI!!!!!
    Testing! Testing! Testing! Testing! This is your nine
    o'clock alarm call!

    See, guys, I told you they still had life left! :)

  • by uncleFester ( 29998 ) on Friday August 10, 2001 @07:51AM (#2124875) Homepage Journal
    The person who submitted the story (Troy Baer) is also the admin of the beast. Troy had an interesting article on the current (previous?) cluster setup at OSC in one of the recent Linux mags (Linux Journal, 2001 July []). To call Troy a proud father of this setup might not be too far off. ;)

    I knew Troy from school, admin-ed with him in the Ohio State engineering labs. Ask him what he's doing with that Aero Eng. diploma nowadays.. ;) Overall, a pretty damn sharp guy. He gets to play with Linux/SGI clusters now, I'm stuck with Alphas & an O2000 in a back room somewhere.

    • He gets to play with Linux/SGI clusters now, I'm stuck with Alphas & an O2000 in a back room somewhere.

      You can come admin these clusters and I'll go work with your Alphas and Origin 2000.
    • The person who submitted the story (Troy Baer) is also the admin of the beast.

      To give credit where credit is due, the admin of that system is Doug Johnson, who has done an enormous amount of work to get this thing working. I'm just a user support guy who writes lots of documentation and happens to dabble in systems stuff like Maui and PVFS in my Copious Spare Time[tm].

  • by wirefarm ( 18470 ) <> on Friday August 10, 2001 @04:32AM (#2125386) Homepage
    "... The old system will be divided into smaller clusters and cascaded to faculty ...

    "Damn. I asked for an iMac, but got this stupid Linux cluster instead!"


    Jim in Tokyo
  • What's the difference between SGI's ia64 compiler suite (Pro64) and the gcc compiler for ia64? I know the Pro64 is GPL, so why are there two different compilers?

    • Try to compile a program with gcc and with SGI's compiler, both with full optimisation.
      Preferably use multi-treaded/multiprocessors sources.
      Run them both and see how the SGI compiled one is much more faster and efficient...
  • IBM has a story about this [], the second cluster "to be installed this summer" already exists.
    Also read The story at NCSA [] if that's not enough for you.
  • by green pizza ( 159161 ) on Friday August 10, 2001 @05:53AM (#2137121) Homepage
    Prepare to lose all karma...

    SGI sucks.

    Most of their hardware is great, as is most of their software. But their head is completely up their ass these days.

    Stagnant desktop machines. Impressive but overpriced big iron. OEM PCs. And a terrible logo. What went wrong? Where to begin??

    Once upon a time there was a company called Silicon Graphics. They got their start by making wickedly powerful terminals to provide 2D and 3D graphical front end to massive minicomputers and supercomputers. Mind you this was two years before Apple introduced the Macintosh and Xerox was still playing with the underpowered Star. Shortly there after they began selling a line of large rackmount, standalone graphical computers that used multiple large boards covered with cpus, fast ram, and other goodies to churn out decent primitive 3D in real time using the GL framework (later called IRISgl, which eventually became OpenGL). This was about the time your dad upgraded from a C64 to a IBM XT.

    Fast forward to 1995. You and I were probably playing with a Pentium 100 and looking forward to the rumored 3Dfx Voodoo card. In that same year, SGI upgraded their Onxy graphical supercomputers to InfinteReality graphics... providing performance on par with a Geforce 256. Except the IR could handle 64 MB of dedicated texture ram and 320 MB of frame buffer. Three IR "pipes" could be installed in a single system, and each pipe could even be broken down to multiple channels. IR allowed the world of graphical simulation to finally approach photorealistic quality with multiple projectors / monitors providing a wrap-around display (keep in mind that much of this was available on a limited scale 1991 with SGI's RealityEngine pipes). Both the Onyx and SGI's non graphical server, the Challenge, received a CPU upgrade. Up to 24 MIPS R10000 CPUs running at 195 MHz (each providing 390 MFLOPS + 390 MIPS) could be installed in the Onyx. The Challenge could take up to 36. SGI's flagship desktop machine, the Indigo2, received upgrades as well. The top of the line model had an R10K/195 CPU, up to 640 MB of interleaved ram, two channels of SCSI, and Maximum Impact graphics (4 MB of dedicated texture ram, 27 MB of framebuffer, and performance somewhere around that of the TNT2).

    SGI's machines continued to get better. Indigo2 was replaced with the Octane. Onyx and Challenge were replaced with the Onyx2 and Origin, and later with the Onyx 3000 and Origin 3000.

    Here we are in the middle of 2001. SiliconGraphics has become "sgi" with a NYSE stock price below $1. Their O2 desktop machine hasn't changed much since 1996, and aside from the new gfx card and faster CPUs, the Octane2 isn't a whole lot different than the original Octane in 1997. Onyx 3000 uses updated graphics based on the original IR from 1995. Perhaps the only noteworthy change has been the architecture of the new Onyx and Origin. Both can scale as a single machine to 512 CPUs with 1 Terabyte of RAM. Many of these massive machines can be clustered together for even more power... at an insane cost.

    The company that brought us 3D on the desktop has pretty much come to a halt. Their desktop machines haven't change much in almost 5 years. Their big iron is impressive, but expensive as all hell. And their PCs... where to begin on the PCs... They tried making what could have been the coolest pair of PCs of all time. But due to delays and driver issues, the machines ended up being overpriced, nonupgradable ho-hum boxes. Pretty soon they hit the other end of the spectrum with generic OEM PCs. And now this, the "SGI 750" Itanium. A box that is identical to that which is being sold by HP and Dell. The only thing SGI about it is the logo. We're not even dealing with the same SGI. This new "sgi" couldn't have possibly come from the same roots as the old, grand, SiliconGraphics.

    I can't help but wonder what the old SiliconGraphics would be doing today. Like another poster pointed out, the Octane would probably have an ever faster architecture, better graphics, and probably 4x the CPU power. This new linux cluster would probably be based on much better machines and using something better than Myrinet (which is limited by the 66MHz/64bit PCI bus the card sits in). The old SGI would have made a complete fire breather, not some OEM stack that anyone could build themselves. The old SGI would have the cube logo *and* rightfully wear it.

    When I look inside my old, used Indigo2 from 1995 what do I see? I see its 750 watt power supply. I see not a graphics card, but *three* massive cards working together and connected to the power supply via a thick jumper cable. I see engineering at its best. I see a product that pushed the limits of silicon and interconnects. I see something that was worth its $50,000 pricetag. I see something that was indeed an order of magnitude more powerful than anything else on the desktop.

    When I look at the current SGI desktop machines, I see something I can buy for less at Best Buy.

    I recently saw a demonstration of the Onyx 3000. One of the demos was a visualization app used by an automobile maker. The app showed a few different cars in full detail across three screens (each 1280x1024) in a panoramic configuration at a sustained, locked 75 Hz + 75 FPS. The cars had complete reflection features that interacted right down to the metallic flecks in the paint. The detail was right down to the 3D textures that made up the subtle surface of the dash plastics and the seat leather. It was truly photorealistic. I've seen the Geforce 3 demos, they were nowhere near as impressive as the car demo.

    Another demonstration showed the Onyx's power at loading textures. The machine they had was connected to several RAIDs containing over 500 GB of satellite and aerial photos. On the same three screens and in the same 75 Hz + 75 FPS were able to zoom down to a national park, pan across to another state, and zoom back out to planet Earth floating in space. All in real time. The RAIDs were clattering so loud I could hardly hear the man giving the demonstration. The Onyx never missed a beat.

    If the old SGI was here today, we'd have that kind of power on the desktop. And it would cost $50,000 and consume 750 watts. Not $500,000 and 9,000 watts.

    And we wouldn't have a Myrinet connected stack of Itanium PCs. We'd have something a whole hellofa lot better.

    [end rant]
    • by Anonymous Coward
      Impressive but overpriced big iron.

      Sorry, but there's nothing overpriced about the Origin 3000 family. I saw a quote for a 16-processor O3400 with 16 GB of RAM; the bottom line at list price was around $500,000.

      That seems totally competitive to me.

      And since I'm posting anonymously anyway, you might be interested to know that SGI is planning to release a new product any minute now. (It was announced to the developer and integrator channels this week). It's a four-processor (MIPS, natch) server in a 2 RU package. They're calling it the Origin 300.

      But the cool part is going to be an interconnect product codenamed Sprouter. It lets you take 2 to 8 Origin 300 systems with 4 procs each and connect them using NumaLink (formerly CrayLink) into a single system image of up to 32 processors.

      At, it's projected, half the price of a 32-processor Origin 3000 system. And for my kind of programming anyway, single-system-image beats the pants off that Myrinet stuff.

      The O300 has 2 66/64 PCI slots, so that's enough expansion to let you attach your basic I/O devices like fibre channel RAIDs and high-speed networking and stuff. Each server comes with USCSI3 built-in, if anybody still uses that stuff. ;-)

      Not everybody needs a medium-scale single-system-image IRIX machine, but I personally do a lot of ImageVision library programming. And ImageVision, being multithreaded at the core, loves big CPU counts. So for me, and people with needs like mine, it's going to be a very cool fall.

      • IRIX is no longer a first tier operating system. New versions of Oracle (just for example) come out for Solaris and (shudder) HP long before (if ever) they come out for IRIX. IRIX is even starting to lose focus on GNU projects. I don't think they'll ever recover that status. It is a shame. The only bright spot (for me) is that I can pick up an O2 on EBAY pretty cheap.
        • SGI can not be judged on Oracle support or other database support (although from personal experience Red Brick (a data warehouse database) kicks ass on an Origin 3000)). SGI is specifically targeting the scientific, creative, analytical and technical users. These users use floating point, or need very large single system image (NOT clusters) or need the graphics that SGI provides. V6/8/10/12 graphics provides 12 bits per component with 10bit D-A's in an Octane. This is VERY unusual in the graphics industry. This has enabled human vision research not possible on any other machine. SGI workstations (Octane2), servers and Onyxes have HDIO (Hidefinition TV I/O cards). You need a LOT of bandwidth to handle uncompressed 1020p I/O. Onyxes have at the moment 256MB of texture memory per pipe. This enable volume visualisation impossible on any other graphics card. This is very important for some forms of medical imaging and for Oil/Gas exploration (BUT NOT ALASKA PLEASE!) SGI has a 1024 processor single system image (NOT a cluster) running at NASA AMES and has shipped multiple 256/128/512 proc SINGLE SYSTEM IMAGE Origin 3000s. Scientists like single system image machines. The quote from one of the nasa guys is it is just like using a desktop workstation, only a bit faster :-) These are not ordinary machines and are not targeted at people running Oracle.
      • Hmm, PCI and no XIO? Would be nice to at least have a couple of each. Though 2 rack units isn't much room to work with. Wonder which version of IRIX it'll run? 6.5.13 + patches? 6.5.14?
    • Great comment!

      Now that SGI is about to be lost would *someone* please contact Dr. James H. Clark?!? I would hate to see this company going down just like Symbolics and Thinking Machines before.
    • About three weeks ago, I got one of those SGI Insider newsletters in my email, with an unbeatable offer for one of their 1600SW monitors. I really wanted an Apple Cinema Display, of course, but for $550 plus tax and shipping, it sure was tough to beat; they're still about $900 on eBay.

      I placed my order straight away, and it still has not arrived. The reason? During this crisis period for the company, where everything is falling apart, they are apparently changing their sales systems to use the latest version of Oracle. During this transfer, their ordering system is entirely manual. They haven't lost my order (yet), but they did take many more orders than they had available machines for, and they claim to still be straightening out the mess.

      I lost even more faith in SGI when I noticed their "configure your SGI system" web page was Windows-based. For shame, SGI!

      Part of this is, of course, the kind of weird degradation that occurs at any big company. But I can't say I have any faith in the company that makes that kind of blunder. Changing your ordering systems to the extent that operations are severely impacted is just plain stupid; I've never managed a major business, but if I were, the minute I had problems of that severity, I'd go straight back to the old system and send developers of the new one back to the drawing board. Elementary, surely?

      Oh, and even though I am surely a beneficiary of a great monitor deal because of this, they should have dumped all the monitors on eBay, ten or so at a time. They would have made, maybe $ 800 per monitor instead of $600. That's a pretty respectable chunk of change right there.

    • by LinuxParanoid ( 64467 ) on Friday August 10, 2001 @08:06AM (#2123076) Homepage Journal
      What went wrong?

      I know this is a rhetorical question, but having once spent a lot of time thinking about how to advise them before and during their fall, I'll give you my analysis. Some of this I saw at the time, some aspects I only saw too late. Learn from their mistakes.

      Here's what went wrong:

      • SGI succumbed to the Innovator's Dilemna. Unwilling to canibalize their high-end graphics, they refused to enter the PC 3D graphics space and left it open for 40+ hungry competitors. Many of their engineers left for said competitors when it was clear SGI was going nowhere. (Jim Clark recognized the dilemna in 1992-1994 by the way and jumped ship himself, a harbinger of things to come.) In fairness, its hard to canabalize a 1-2 billion dollar workstation graphics market in hopes of winning a 50-200 million dollar 3D PC graphics one.
      • SGI refused to go to NT early on when they would have had leverage in making the move that could have forced/encouraged MS to adopt OpenGL exclusively for 3D. Instead, they said no to NT for too long, and when they said yes, it was a me-too decision that was later partially reversed in favor of Linux. Rather than recognizing and admitting they'd lost the war and pursuing the best possible terms, they chose, either conciously or through inaction, the "go down fighting, maybe we can still win" route.
      • SGI's bread and butter midrange workstation 3D graphics was prone to "good enough" copying by competitors, Sun and HP. SGI's engineers spent a lot of time focusing on developing unique high-performance texture mapping serving 2% of their market (the entertainment sector) rather than on improving geometry engine performance further for the benefit of the biggest 40+% market (CAD).
      • SGI's choice of a strategic response to PCs was poor: "We'll have highly differentiated systems" (the O2). Unfortunately, the differentiation (UMA, texture mapping, imaging, system bus architecture) was largely in areas that didn't add much value to their largest segments of customers. They built not what most of their customers wanted, but what the "cool" customers wanted. What most of their customers wanted was lower prices- that's what most of them ended up going to when dumping SGI.
      • SGI engineers were late. Whether through lack of focus/discipline, resistance to "impossible" marketing schedules (that turned out to be necessary), choice of agressive cutting-edge/bleeding-edge component technologies that proved hard to debug, whatever. Your pick. Key products in the timeframe you mentioned were late, late, late. The midrange IMPACT graphics were announced June 95 as shipping but in reality didn't really ship for another 6 months, more or less. (In the meantime, Wall Street lost faith in the company as a momentum stock and SGI stock price dropped from its alltime high of 45 down to mid-20s.) Subsequent products also had a tendency of being late (O2, a year later than needed, Visual PC was late, etc.) SGI engineering exhibited a lack of discipline when instead they needed increased focus to adjust from product design cycles of 4 years (traditional workstation graphics) to 6 months (90s PC graphics). In their defense, this wouldn't have been easy. But at least some there knew about this. Which brings us to the last problem I'll go into.
      • Arrogance. SGI was arrogant. No PC could beat us. We'll always stay ahead. Sun? HP? Ha! Yeah, we can do low-price graphics, look at Nintendo-64; see a PC beat that! etc, etc. Not everyone at SGI there was, but a heck of a lot were.

      P.S. I didn't even get into their server strategy, Cray, and later events. Another time perhaps.

      • Well sadly enough i can only agree with you.

        I actually do not have any hope left for SGI. Here is why:

        -Their workstations do not cover enough markets to sustain themseves let alone generate enough revenue to set them back ahead of the pack.

        -Their single image clusters are not cost effective enough for the scientific comunity and their use for Visualisation, where people would be willing to pay the insane price, isn't large enough.

        -Anybody can build UNIX servers.

        -Anybody can build MPI clusters.

        So I think they are reduced to niche markets which will not cover their cost in R&D which means they will have to license technology or buy components from others (CPUs, bussystems etc.). However they might run out of breath in the time they redesign their gear to take advantage of the new tech, and reduce the production cost.

        So my guess is they will be consumed slowly by their competitors - lets only hope some of their tech remains.
    • by Anonymous Coward
      If I remember correctly, in about 1996/97 this guy went to work for SGI. He'd already had similar high-up jobs at two other companies that lasted nearly 6 months, just like his stay at SGI was going to. What he did was to go around all of these companies saying that they needed a "Windows NT strategy"
      The strategy was to go NT4.0 on commodity (intel) hardware. So, SGI announced that it was reducing Irix development, halting development of the MIPS processors (which were an order of magnitude faster than the Pentium of the day and 64-bit to boot).
      Very quickly, he was looking for a new job, SGI had penium machines that no-one wanted running NT (and Linux for the better informed customer), had restarted MIPS development and continued with Irix. However, by that time they had lost their lead.

      I hope he lost all his money in the dot com mania.
    • by Anonymous Coward
      Well said - I agree with most of what you've written, and think that you've put it all very well.

      However, I think the reason that SGI is not producing a desktop version of Onyx 3000 is obvious - SGI tried to do battle with Sun, etc. and failed. SGI tried to do battle with Dell, etc. and failed. They're not about to do the same thing to NVidia...

      The original SGI targetted what was at the time a niche market - 3D graphics. It looks like the new SGI will also retreat into niche markets - very high-end graphics and compute servers.

      You're also right about the Itanium server - there's nothing very interesting about it. I believe this machine is only intended as an interim solution to allow developers onto the platform until SN-IA is available (whenever that might be).

      Then we'll see something a little more impressive than OEM Itanium boxes with low-bandwidth Myrinet interconnects!

  • by peter303 ( 12292 ) on Friday August 10, 2001 @09:09AM (#2141323)
    It took MS 15 years to have a full 32-bit OS
    after those chips came out. Hope they are faster
    this time. 32 bit NT on an Itanium would be a waste.

    SGI and SUN have had full 64 bit OS for 7 & 5
    years. Yes, there are bugs to shake out in the
    beginning. OF course Bill & Steve will announce
    they are "just about to ship" for years until
    they do.
    • c'mon. It took MS that long to get some competent OS engineers working for them. Hopefully this time the process will be faster. 64-bit VMS!! Go, Cutler, go!!
    • Correct me if I am wrong...

      But hasn't there been a 64 bit version of Linux for a VERY long time - ie, for the Alpha?

      What I find interesting (and it is just a personal conspiracy theory of mine, and probably holds zero water) is that it took "this much" time for Intel to release their 64 bit chip - how long have we been hearing about it now? At least 2 years...

      Is it just a coincidence that Microsoft finally has a running platform for it just at the time this chip comes to market?

    • Just be glad that Apple isn't the company doing it. It took them 16 years to get a 32-bit OS after their computers started using 32-bit chips, and they already had 23 years of OS writing experience. Contrast that to Microsoft, which took 6 years with only 14 years of OS experience.

      Want innovation? Who do you think has it? Also, one company uses a UNIX based OS; the other at least tried to fix the mistakes of the past, although they did make more in the process of doing so.

  • Apple knows that at present, the Itanium (which is based on a RISC-like design scheme called VLIW, or EPIC) is stuck at 800MHz even in its prelease form -- slower even than the shipping PPC 7450 (G4) which is running at 867MHz and expected to cross the GHz barrier by year's end. The Itanium, while offering many important features lacking from previous Intel chips, has also been criticized for its poor performance - particularly when running existing x86 applications and operating systems. Apple's next-generation processor is the PPC 7500 or G5, which is also 64-bit and employs the first complete architectural revamp since the first PowerMacs shipped in the mid-90's...but the G5, unlike Itanium, can process existing 32-bit PowerPC instructions at full performance and is expected to continue to scale upward in clock rates; the initial G5s slated to ship in early or mid-2002 are currently projected to run at 1.2GHz with per-clock performance targeted for roughly 65% beyond Itanium.

    Also of note, IBM has stated that current plans for the G5's SIMD/AltiVec engine specify a 256-bit system, rather than a 128-bit one in the G4. This will be one kickass CPU.

  • Itanium? (Score:3, Funny)

    by Bobo the Space Chimp ( 304349 ) on Friday August 10, 2001 @11:20AM (#2153148) Homepage
    Dr. Adams: "Welcome to the Silicon Graphics Tantalus V Itanium research campus."

    Stan: "Why did you call it 'Itanium'?"

    Dr. Adams: "I have a rare marketing disease that prevents me from pronouncing the first 'T' in 'itanium.'"

    • "Presume there is something that cannot be labeled. Call it 'X'."

      Hrm.... Malcolm X or Mac OS X?? Kinda messes with your head doesn't it?

  • IA64 & Myrinet (Score:2, Informative)

    by ShavenGoat ( 63696 )
    So you guys know, Myrinet is a 2Gb peak interconnect with a 7us minimum latency. FULL CROSSBAR SWITCH :-) Fiber or serial.

    A interesting fact is that up until a few days ago, Myrinet only supported 1 GIG systems. I ran into this while setting up the University of Nevada [] beowulf named cortex.

    I must admit, IA64 with Myrinet 2000 is gonna kick some serious computational ass.

    The article says that Myrinet will run MPI, but it will also run PVM and TCP/IP stuff too.

    Check it out at their site []

Feel disillusioned? I've got some great new illusions, right here!