Wandering Thoughts archives

An advantage for hardware RAID over software RAID

I am generally fairly negative on hardware RAID; I feel that both in theory and in especially in practice, it is almost never a benefit. However, today I realized that there is one way that a hardware RAID card could have an advantage: avoiding PCI bandwidth limits during RAID reconstruction.

In the general case, RAID reconstruction has to read all of the remaining intact disks and then write back to the new disk. With software RAID, this data must cross the PCI bus, since it is the server's main CPU and RAM that do all of the work. With hardware RAID, nothing crosses the PCI bus; it all happens on the card.

But is the PCI bus going to be the limiting factor? I think that it's at least possible. There is some evidence that our iSCSI targets are PCI bandwidth limited for sequential reads with 1 TB disks; they can read from each individual disk at around 105 MBytes/sec, but if we try reading all 12 at once, we get only around 59 MBytes/sec from each disk (for an aggregate 708 MBytes/sec, much less than the theoretical 1260 MBytes/sec we'd get if we could drive each disk at full speed).

(We were reading from the raw device, so there was no filesystem overhead. Which isn't to say that we weren't running into some other kernel performance limit, instead of an intrinsic hardware one. And for that matter, the hardware limits may be in our ESATA controller cards instead of in the PCI bus, although at that point it doesn't make a difference for planning systems; if you can't get an ESATA controller that works fast enough but you can get a hardware RAID controller that does, you don't care too much about exactly why the ESATA controller isn't fast enough.)

One might say that RAID reconstruction is an obscure corner case that's not worth optimizing for. Well, yes, but on the other hand when it happens people tend to care a great deal about how fast you can return your RAID to full protection (and get upset if it is not pretty fast).

Another source of stickyness for social web sites

Recently, I've started actually doing things with my Facebook account, and I've done a bit with Twitter, and of course I've used LiveJournal for a while now. All of which, especially Facebook, has recently given me a bit of additional perspective on something.

You know all that stuff that I wrote about what makes social networking sites sticky? Sure, it's accurate as far as it goes, but I missed a big bit of it: time. Namely, the sheer amount of time it takes to keep up on each new site.

If people are actively using a social networking site, they're generating new content; tweets, LiveJournal entries, Facebook status updates, you name it. You have to keep up with all of this, and the more social networking sites the more time you get to spend on it; sooner or later you run out of time. The more time a social networking site can get you to spend on it, the less time you have to be anywhere else and the stickier it is.

(From this perspective, all those peculiar Facebook applications strike me as diabolically clever; they are a giant flytrap, trying to get you to spend more of your time on Facebook instead of somewhere else.)

So why does the number of social networking sites matter? One would think that all that matters is the total amount of updates, regardless of how many websites they're distributed across, and the total amount of updates would be more or less constant, since people only have so much free time to generate them.

I have two theories about this issue. The first is that it doesn't entirely matter, but that a site that you're already invested in has an easier time persuading you to spend more time there. The second is that there is a natural limit to the amount of updates that a social circle will tolerate on any single website, for reasons similar to how planet aggregators have a natural size limit; too many updates roll over people's front pages too often. Generate too many updates and you will get social pressure to cut back. But new websites create new front pages (and possibly different social circles too), and thus let the very active content generators cut loose again.

Users are lazy

Here is something important to remember when designing systems and interfaces: users are lazy. Worse, not only are users lazy but they're very good at detecting pointless work.

What is pointless work? Simple: it's work that the user doesn't see any visible benefit from performing (or doesn't understand the benefit and so discounts it, or feels that the benefit is a lot smaller than you're making it out to be). Of course, the work is not pointless to you or to your application (well, hopefully), but the user doesn't care about that, all they care about is what they can see.

It is useless to ask users to do pointless work. They won't. They're (rationally) lazy.

(If you force them to do it anyways, they will pick default answers or fill in the simplest possible values. If you make them work too hard at that, they will discard your program.)

The best way to deal with this is to make users do as little work as necessary; you should ruthlessly eliminate pointless work, and when you're figuring out what's pointless, remember to view it from a user's perspective, not from a system designer's view. The corollary to this is that if you absolutely have to make users do work, you should try hard to give them a visible benefit from it. The visibility is important; generally, a big but hard to see benefit might as well not exist.

(Fundamentally, this is why things such as the accidental BitTorrent problem are so intractable. You could solve the problem by getting users to configure whether or not their BitTorrent client should run on each network they connect to, but to most users, configuring the characteristics of the various networks that they connect to is pointless work, so they just won't do it.)