Software and hardware annotations 2007 June

This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.

[file this blog page at: digg del.icio.us Technorati]

070609 Slow remote X display with Exceed and antialiases fonts

A colleague showed me how slow was the GNU/Linux version Eclipse when viewed on MS Windows via the Exceed X server. Since there was no good reason for this, and display using VNC seemed fast, I noticed that the GUI was using anti-aliased font rendering, and checking with

xterm -fa 'mono:size=10:antialias=0 or 1

showed that antialiasing was indeed the issue. Even enabling the RENDER extension on the X server did not improve things. Strange.

070602 Software versus hardware RAID: bandwidth, latency, convenience

During an online help session someone asked about the advantages and disadvantages of software and hardware RAID. Well, they relate to performance and convenience, as well as price.
One of the major performance differences is about host bus traffic: for RAID arrangements with some redundancy (mirroring, parity, ...) a hardware host adapter saves transferring that degree of redundancy over the system bus. For example for mirroring under software RAID each written block must be transmitted over the system bus twice, but only once with a hardware RAID host adapter.
The same or more applies for example to RAID5 (n+1) in case of a read-modify-write transaction (for a partial stripe update) software RAID must read the other n-1 data members of the stripe and them write back the whole stripe over the system bus, but one needs to send only the single block to update to a hardware RAID host adapter.
Another major performance difference is often over latency: here usually software RAID has the advantage as usually the low power consumption, embedded CPUs used in hardware RAID host adapters are much slower than recent host CPUs. It is possible for a hardware RAID host adapter to add 2-3ms latency to each transaction.
As to convenience, hardware RAID usually is far nicer than software RAID, as often it provides a simple single virtual disk interface to the host operating system, which therefore can be configured with no special casing for RAID operation other than tuning. Software RAID instead requires boot loaders and kernels with special modules to handle the RAID operation. Fortunately kernels like Linux implement RAID1 in such a way that volumes which are members of a RAID1 have almost exactly the same layout as a non-RAID ones, which simplifies things like recovery. But software RAID still makes boot and configuration more fragile.
Hardware RAID is therefore more transparent to the operating system, but this means that it is harder to monitor and tune a hardware RAID setup, while all the usual and often extensive tools of the host operating system can be used for a software RAID. Some hardware RAID host adapters offer interfaces that provide some access to the status of the underlying array members, but this is often unsupported or not as well supported as access to native devices.
My impression is that hardware RAID is better for smaller systems where ease of setup is important; for larger systems perhaps software RAID is better, as system bus bandwidth concerns can be eased by having multiple system buses and other high end hardware features. But it is hard to imagine general cases. It is somewhat amusing to me that ease of setup is then what drives the adoption of strange RAID based things like SAN servers with virtual disk drives.