The T2000 have many slow CPUs but rather fast IO.
I did some performance tests with the T2000. The CPU is too slow to beat any current one from IBM (Power), AMD or Intel.
My first test was building kernels. With -j32, a complete build needs about 9 minutes. For comparison, a 4-way UltraSparc 2 with 450MHz needs 30 minutes. So each core compares to an UltraSparc 2 with 700MHz.
This numbers are not that phenomenal, so I added another test with ccache, to realy use the io system. With empty cache, it needs 10 minutes, with filled cache it needs 2.5 minutes.
As application server, it is not that usable; they are cpu bound. Especially zope, which is known to not scale well on more cpus because of the python global interpreter lock, is not able to use this. A comparision with an Opteron 242 with 1.6GHz shows a factor of 5 in the computing power on virtual cpu.
Some people already know it, I got a new machine to play with.
It is a Sparc running Debian etch:
# uname -a Linux zee 2.6.17-2-vserver-sparc64 #1 SMP Sat Aug 26 12:28:58 UTC 2006 sparc64 GNU/Linux
The kernel is not yet available in Debian, it is handbuilt. But I hope that this will change soon.
It is a small machine with some CPUs:
# grep ncpus /proc/cpuinfo ncpus probed : 32 ncpus active : 32
It only have a little bit of RAM:
# grep MemTotal /proc/meminfo MemTotal: 33257432 kB
And really too less disk space:
SCSI device sda: 143374738 512-byte hdwr sectors (73408 MB) SCSI device sdb: 143374738 512-byte hdwr sectors (73408 MB)
Yes, it is a T2000 from Sun with 8 real CPU cores:
cpu : UltraSparc T1 (Niagara) fpu : UltraSparc T1 integrated FPU prom : OBP 4.19.0 2005/10/27 17:24 type : sun4v
Each of the 8 cores can run 4 threads at the same time, Sun calls this CoolThreads, and Linux sees this as virtual CPUs.
Yes, the xen images from linux 2.6.16-18 in unstable does not work with the currect xen 3.0 in unstable and testing. The interface for the priviledged domain changed in an incompatible way. I'm working on that problem and 2.6.17-7 will contain a complete new infrastructure.
I think the current situation is rather clear. Our current kernel contains firmware blobs for some hardware. They are relicts from the time where the firmware loading infrastructure did not exists. It may be possible to move them outside, but such patches was rejected to keep compatibility.
Some people clearly stats, that they think, this violates paragraph 2 of the DFSG. I must say, I'm not sure. This paragraph say: The program must include source code. Now source is not defined and opaque data have no defined form of source. The data is opaque as it is not possible to say, what it includes. (Some people wanted to differentiate between executable code and configuration settings, but there is no way to see what it is.)
If we remove them from the kernel image, we make many users unhappy. Many of the widely used hardware like TG3 and some storage adapters will just stop working after a kernel upgrade. There is also no clean upgrade path. Even the installer infrastructure is missing and I don't think they will be finished for the release of etch. Therefor is think, such a removal will even violation paragraph 4 of our Social Contract which say: Our priorities are our users.