By Timothy Prickett Morgan

The word coming out of Sun Microsystems is that it will be making some enhancements to its Enterprise 10000 Starfire line of enterprise Unix servers in a few weeks. The exact nature of the announcements is as yet unclear, but odds are Sun is working on putting faster chips in the Starfires, which currently use 400MHz UltraSparc-II processors rather than the faster 450MHz versions that are available for Sun’s workstations. But Sun could go as far as offering 480MHz processors, which it has been whispering about delivering for some time, but that faster part could be delayed until the first quarter of next year.

Sun is of late coming under fire at the high end of the Unix market, a situation that the vendor has avoided for the better part of two or three years thanks to the advanced SMP technology it picked up from Cray, and which enables it to gang up 64 processors in a single system image. But IBM is pushing very hard with its S80 Condor servers, which use its copper-based 450MHz Pulsar processors, and is reportedly almost sold out of the boxes for the year.

Of course, no one knows what IBM’s build plan was for 1999 for the Condors, so that may not mean all that much. Still, the S80s offer considerably better uniprocessor power and slightly better scalability than the Starfires, and that gives IBM a story to tell. Hewlett-Packard has also just announced the availability of its 550MHz PA-RISC 8600 part several months early, and should be shipping it in workstations soon and in midrange L-Class and N-Class servers by the turn of the year and in high-end V2500 server by January of February if all goes well. HP’s exact schedule is as yet unclear.

The point is, Sun needs faster processors to compete, just as it original roadmap made clear when it said it would try to get the 600MHz UltraSparc-III Cheetah chip out the door about now. Sun is expected to have the Cheetah in workstations and low-end servers in early 2000, but they won’t show up in the high-end Serengeti follow-ons to the Starfire servers until around August or September 2000. Sun will have to do a lot of fast-talking to compete against IBM and HP between now and then to keep, or see its former fast growth slow down. If Sun can put Cheetahs in existing Starfire frames, it may start doing it sooner than its plans say it will for competitive reasons. Being about to talk about 1,000-way SMP scalability for the second half of 2000 is not nearly as important as keeping business away from IBM and HP.

Sun could also announce that it is moving forward its expansion of the SMP scalability of the Starfires in conjunction with a more modest 450MHz or 480MHz UltraSparc-II chip crank. By moving to either faster processor, Sun could show better TPC-C online transaction processing power than IBM’s RS/6000 S80, which processors more than 120,000 TPC-C transactions per minute. The 64-way Starfire with 450MHz UltraSparc-IIs should be able to top 130,000 TPM, and with 480MHz processors should be able to hit almost 140,000 TPM.

This isn’t a lot more than the S80, of course, but it is something. It is hard to say how much more power Sun could pack in a single frame if it boosted the SMP scalability just to 128-way processing in the interim as it readies the 1,000-way Serengetis. By its very nature, SMP doesn’t yield very efficient results beyond 32-way processing for single system images. Indeed, a 24-way Starfire using 400MHz processors can deliver about 58,000 TPM, but the 64-way Starfire delivers only twice the performance even though it has 2.7 times the number of engines. Moving beyond 64-way processing will yield worse degradation and quite frankly is only really useful if customers want to carve up the processors in a single frame into many virtual computers with logical partitions.

If Sun could get similar scalability efficiencies on the 128-way Starfire machine as it does on the 64-way box, it might get performance as high as 175,000 TPM. But it is hard to say since no one has ever really provided such SMP scalability in a single box before.