Dr. Anthony Earl this week and got an Athlon X2 3800+ dual-core box. I expressed some interest in poking at it to run some particular tests against it, and he was gracious enough to invite some of us Hacking Society geeks over to poke it with a poin-ted stick. It was a very successful afternoon, and made delightful use of the "fall back" daylight savings time hour.

Ant had found an Antec case that's fairly nice looking, a good size for holding what he wanted in it, and was under $60 without power-supply. Once of the neat things about it that I hadn't seen before was a hole in the side of the case with a duct to get air directly from the outside to the CPU.

It's a pretty nice case, but I'm actually kind of glad that I chose a different case for a recent computer setup I did at home. Ant's case can handle the SATA drive enclosure, because of the depth of the case. Mine can't, so the enclosure sticks out about 3 inches at the front. My case is quite a lot smaller though, it's meant to just take a Mini-ATX motherboard. The Antec case is a monster, but beautiful. Of course, I paid almost half of what he did, and that included the power supply.

I tried running memtest on it, and was a bit surprised by the performance it was reporting. 16GB/sec for L1 cache, 4GB/sec for L2 (1M) and 2GB/sec. The P4 3GHz systems I've run it on show 21/16/2.6GB/sec (respectively). Odd that there's a factor of 4 difference between the L2 access reported for the two CPUs. Of course, on a per-clock cycle basis, the Athlon is faster at both L1 and main memory access. I realize that memtest is not a benchmark, but it makes me wonder what the story is.

For those that don't know, that 3800+ is a 2GHz CPU. Also, the X2 3800+ only costs around $330, while the P4 3GHz costs around $180. So, per core the Athlon is a less expensive CPU. I'll be getting a Dual-CPU Opteron in next week, so it'll be interesting to see how the 2GHz CPU there compares.

One thing to note is that even when we were doing a Xen build (including several kernels), the CPU heat-sink was rather more cool than the P4 systems I'm familiar with. The P4s are using these massive copper CPUs with tons of air-flow (they're servers so they can be loud). The Athlon dual-core was running what looked like an aluminum heat-sink with much lower air-flow, and was still cooler. Again, far from scientific.

The real fun began when we started working on the things Ant really wanted on the box: Xen running to allow the box to be partitioned into both a desktop and a web server for for his personal sites. This poses several challenges: Xen doesn't support 64-bit platforms, and it's ability to run X in Domain 0 has been spotty.

My research a few months ago said that Xen plans to support 64-bit in the 3.0 release, but stable is currently 2.x. However, SuSE is shipping what it calls Xen 3.0 (which seems to be just a pre-release version), and we were able to get it running on the test SuSE install that Ant did. We found out later that SuSE's Xen kernel not only supported AMD64, but also includes the sata_nv disc driver.

SuSE did not, on the other hand, support the frame buffer graphics driver. We were using that for video because the on-board GeForce 6100 has some problems with the native NV driver for Linux. The VESA driver worked just fine though.

Ant switched back to Ubuntu to try again, and did an install of Xen there. Unfortunately, Ubuntu and Universe don't have packages for Xen, so it was a manual install. We mucked around a while with trying initrds before realizing that the stock Xen 3.0 beta release doesn't build kernel drivers for the sata_nv driver, which is what his disc is connected to.

Let me just say that Ubuntu's mechanism for building initrds is not good. First of all, in Breezy it just doesn't work. You have to do this kludge with "-k" to keep the temporary file around, and then run "mkcramfs" on that temp directory. Luckily, I came across that fix pretty early in my searching, once I realized that Ubuntu used "mkinitrd" just like Fedora, it just wasn't installed.

I will say that Fedora's mkinitrd is vastly superior though. It has options for doing useful things like "--omit-scsi-modules" and "--with=modulename", "--preload modulename", and even "--nopivot". The "--omit-*" options are extremely useful if you're trying to build an initrd for the Xen kernels which already have SCSI, LVM, and RAID modules built into the kernel, but need initrd for the udev setup.

Eventually we tracked down that it didn't have the sata_nv driver. This was partly masked because Ant had copied an example grub.conf entry from a web-site which was using "root=/dev/hda1" instead of "root=/dev/sda1". We finally decided to just rebuild Xen kernel from sources with the sata_nv and FB drivers built into the kernel. We then rebooted into Xen and X started up.

I noticed that performance of X was noticeably slower under Xen. We quickly found that this was because Xen was running the Dom0 with only 123MB of RAM, so just starting X caused it to swap pretty hard. Upping that to 700MB caused the performance to increase quite dramatically. In fact, I'd have to say that Breezy is aptly named, no pun intended. Starting Star Office and Firefox was fast. Of course, I mostly run it on my laptop which has both a slower CPU and a much slower hard drive.

We then ran into problems with the Nvidia network board. Firstly being that we didn't have the driver built into the kernel. When we did, it would show up but without a MAC address and wouldn't send or receive packets. I suggested we try a different network card, and after adding an old 3Com Vortex board to the system it came up and was working great.

We did run into some weird problems though. One was with the Nvidia Ethernet, of course. However, the weird one was that we rebooted with the dom0 memory specified as 500MB, checked with "top" that it was 500, and then started xend, and it suddenly was 123MB again. I could run "xm set-mem" to push it back up to 400MB, but once I did that I couldn't change it again, either up or down. A later reboot it came up with the full memory and stayed that way without using mem-set. I don't know what the story there was. I'm guessing a bug in Xen.

So, if you've been wanting to run Xen on a machine that you need X on, it looks like it's getting to the point where it's usable. I hadn't tried it in the past, but I know several people who have and had problems such as lock-ups.

Xen is still a little rough, but SuSE is moving in the right direction there. Fedora 4 shipped with Xen kernels, but I've never had any luck with them. SuSE's worked, but were still missing some drivers. I expect that over the next year we'll see Xen mature a lot, both it's own code (which isn't too bad as it is) and with it's packaging for distributions.
(Post Reply)