Introducing the T2000 server

The Sun fire T2000 is more than just a server with the out-of-the-ordinary UltraSPARC T1 CPU. 16 DIMM slots support up to 32Gbytes of DDR2-533 memory. Internally, there is room for 4 SAS 73GB, 2.5" disks. Don't confuse these server grade disks with your average notebook 2.5" disks. These are fast 10.000 RPM Serial Attached SCSI (SAS) hard disk drives. With SAS, you can also use SATA disks, but you will be probably limited to 7200 RPM disks.

Four Gigabit Ethernet ports and 3 PCI-Express (supporting 8x, 4x and 1x low profile cards) and 2 x PCI-X 133MHz/64Bit low profile card slots allow you to add more storage via DAS, NAS or SAN racks.


The T2000 in practice

The T2000 is a headless server. To get it up and running, you first access the serial management port with Hyperterminal or a similar tool. The necessary RJ-45 serial cable was included with our server.

This way, you get access to Sun's Advanced Lights Out Manager (ALOM), which is a system controller that runs the necessary console software to administer the server. Running independently of the main server using standby power, the ALOM card is ready for operation as soon as power is applied to the server.

Once you have given the SC net management port an IP address, you can remotely manage and administer the server over a dedicated network, and you no longer need the serial connection.

The console software offers you plenty of different commands to administer the T2000 server.

From within the administrator console, you can get access to your Solaris installation in the screen output of your T2000 server. You can always get back to the management console simply by typing "#.".

While using Putty or a similar SSH tool, combined with the fact that the T2000 is a headless design, it might give you the impression that the T2000 is Command Line Interface only; you can get access to the sleek GUI of Solaris. After browsing the file system through an ssh shell, we noticed that an Xorg server was installed. Since Solaris uses the Java Desktop Environment, which is based on Gnome, the Gnome Display Manager (gdm) was also installed. We reopened an ssh connection to the Sun, with X11 forwarding enabled. You can run 'gdmsetup' as root, where we could enable or disable XDMCP. After enabling it, we were able to connect to the Sun using Xnest, or by running our local XDMCP chooser. XNest showed Solaris in all its GUI glory...

The GUI offers more than pretty pictures: Solaris Management Console (SMC) is a very intuitive tool that gives you a very detailed overview of the installed hardware configuration.

Some hardcore administrators may feel that real administrators only use Command Line Interfaces. However, it is our experience that the SMC (GUI version) is a very helpful and useful tool.


RAS

Traditionally, Sun systems have been known for excellent RAS capabilities. Besides the obligatory redundant hot swappable fans, the T2000 also incorporates dual redundant hot swap Power.

Sun also claims that the T1 CPU excels in RAS. See below for a comparison between the RAS capabilities of the current Xeon and UltraSparc T1 (source: Sun).

Sceptical as we are, we decided to give Intel a chance to criticize this table, but it seems that Sun was honest.

In fact, current Intel production Xeon Paxville processor - which find a place in similarly priced servers as the T2000 - do not support Parity checking on the L1 I-Cache - Tag. Intel also pointed out that the upcoming Woodcrest CPU will have improved RAS features.

So, it seems that right now, the Ultrasparc T1 outshines its x86 competitors.

The T2000 also features Chipkill(memory), which complements standard ECC. According to Sun, this provides twice the level of reliability of standard ECC. Chipkill detects failed DRAM, then DRAM Sparing reconfigures a DRAM channel to map out failed DIMM.

Each of UltraSPARC T1's 4x memory controllers implements background error scanner/scrubber to reduce multi-nibble errors - programmable to adjust frequency of error scanning.

When it comes to RAS, especially the cheaper T2000 (with 1 GHz CPU), there is not an equal at their price point in the server market.

Index First x86 competitor: MSI’s K2-102A2M and Opteron 275 HE
POST A COMMENT

26 Comments

View All Comments

  • drw - Friday, March 24, 2006 - link

    Based on the kernel versions listed, I assume that a 32-bit distro was used?

    If so, am curious how a 64-bit distro would compare, as both Apache and MySQL benefit greatly by 64 bit.
    Reply
  • JohanAnandtech - Friday, March 24, 2006 - link

    Fully 64 bit. uname -a clearly indicates 64 bit Reply
  • defter - Friday, March 24, 2006 - link

    quote:

    At first sight, Sun has won the performance/watt battle for now


    Dual Opteron 275HE had 5% higher power consumpion (198W vs 188W), but it was 5-30% faster (depending wherever or not gzip was used). These results would suggest that dual Opteron has won performance/watt battle in this benchmarks.

    Pricing is also quite important. What's the price for dual Opteron 275HE server with 8GB of memory? About $5000-7000?
    Reply
  • PeterMobile - Friday, March 24, 2006 - link

    Definitely interesting to see a 3. party review of the T2000. I think it could also be interesting to compare both the Sun machine and the x86 servers to an IBM p5 510Q. That's a 4-way 1.5 GHz Power5+, which including 4 GB RAM and 2 Ultra320 disks lists for $8,536. Reply
  • Calin - Friday, March 24, 2006 - link

    I saw there is almost no loss of performance for compressing data... how about encrypting it? Reply
  • cxl - Friday, March 24, 2006 - link

    quote:


    The very common ADD instruction is executed in one cycle, but it takes no less than 29 cycles to multiply and 104 to divide. Faster mul and division would have taken up much more die space and consumed much more power. Considering that those instructions are very rare in most server workloads, this is a pretty clever trade-off.


    Actually, MOD operation can be very important for servers, as it is basis for any hashing operations, commonly used in many server applications. E.g. to identify variable in a script, interpreters routinely use hashtables.

    114 cycles per MOD operation is performance disaster.
    Reply
  • Calin - Friday, March 24, 2006 - link

    The performance in the tested configuration was quite good - I wonder how other benchmarks and maybe other "twists" of the benchmark tested would look like. Reply
  • cosmotic - Friday, March 24, 2006 - link

    quote:

    Last, but certainly least, Sun’s solid engineering has impressed us.


    Did you mean certainly NOT least?
    Reply
  • JohanAnandtech - Friday, March 24, 2006 - link

    definitely ... Fixed. Just checking if you read it carefully :-) Reply
  • cosmotic - Friday, March 24, 2006 - link

    Why no graphs? It makes reading benchmarks SO much easier. Reply

Log in

Don't have an account? Sign up now