T1000 in more detail

I've been testing a Sun T1000 now for about the last three months. This was after I said goodbye to my T2000, with much sadness, back in May.

At first glance, the T1000 and T2000 look like the same basic construction, but with the T1000 supporting fewer internal drives. That's not completely true - the T1000 is only 1U high and to keep with the necessary cooling and the reduced height, some of the internal elements have been trimmed too. The less complicated internals should in theory be a bonus, because with less complicated components, and fewer numbers of them, there should be fewer things to go wrong, which in turn should have a real impact on the MTBF (Mean Time Between Failures). It's difficult over three months to say that categorically, but the theory is sound.

For example, there are only 8 DIMM slots (supporting up to 16GB RAM) and only one PCIe slot, although the CPU stays the same with a T1 with 4, 6 or 8 cores running at either 1GHz or 1.2GHz. There's also only one PSU on board, and support for only two hard drives (SATA or SAS) with no CD-ROM/DVD-ROM option available.

This is because the T1000 is seen more as a compute box, either as part of a larger web environment or within a grid system where the CPU power (and particularly simultaneous power) are more of an advantage that massive amounts of disk space. In fact, you can very easily imagine a rack with a T2000 to provide core storage and database facilities and 10-20 T1000s providing the raw computing power.

The idea of a higher power and high-throughput box is also clear from the four Gigabit Ethernet interfaces; you can again imagine have a dedicated switch and interface for your DB and another for an NFS share of the shared components, with the last two ports used for redundant end-user connectivity.

The 1GHz, or even 1.2GHz seems like a low rate, but you only have to consider the modern web environment (lots of a small, often targeted, queries) to get information to see the raw power is not so vital. I've talked before about this, but my continued testing only goes to prove it. Pulling out small fragments of data from your DB onto a web page requires very little processing. To reach high numbers of web transactions of this type, you need a large number of machines to achieve it; or a T1000/T2000 which can do this 32 times. Each core is slow compared to a modern Intel, AMD or UltraSPARC, but it's the principle of the bus over the motorbike - you can go quick on a motorbike, but take only one person. With a bus, the rate may be slower, but you can carry 50 or more people in the process.

I'm still compiling the results (and see my comment on the CoolStack for reasons why the testing isn't finished) compared to the X2100, but it's clear that the T1000 wins out once you start to ramp up the simultaneous requests. About 64 simultaneous web requests the X2100 started to slow down noticeably. Above 128 and I started to see dropped requests, particularly on the heavier Cheffy code (compared to simpler single requests and blog posts).

So far with the T1000 (with little optimization) I've managed to achieve 256 of the smaller simultaneous requests with only a small dip in per-request performance, a test that the X2100 showed a noticeable slowdown as the number of requests increased. I'm expecting the figures to differ little as I increase the number of requests and for the figures with the SAMP Coolstack to show even more improvements.

As always, the other side of the Niagara chip and architecture is the lower power consumption. I'm sure many companies would prefer the lower running costs of the T1000 which can be much as a quarter of a traditional box, usually with faster performance. In my own tests, at high load, the T1000 consumed about 25% less than the X2100, not as low as you might think, but T1000 has a lot more RAM than the X2100.

I'll be compiling the final results (and running more tests) at the beginning of next week.