Friday 4 February - there are now 693 results in the Fhlushstone database, most of which are even valid. The ones which aren't just won't be shown in the stats, so there. But we still need more! More! Keep 'em coming. Tell your friends. Benchmark your Commodore 64! Your cellphone! Your coffee machine! Hell, they all run Linux or NetBSD now, right? Coming soon - select results by OS, machine, whatever, and maybe (depending on how the weekend goes) some actual analysis. Thanks, too, to the folks at LWN for the "Linux Link of the Week" accolade. Next stop Slashdot, eh?
Sunday 30 January - jeez, I go away for a couple of days, the page gets mentioned in NTK and of course, the CGIs break. You can stop mailing me now - it wasn't anything to do with permissions, it was broken by an Apache upgrade.
Monday 24 January - gosh, this page was link of the day over at User Friendly yesterday. The proof is here - what, me, honoured? Oh, and you can now see sorted results. Woohoo.
Most benchmarks today are effectively random numbers, so I thought I'd make my very own random number generator to measure the most important performance indicator of any UNIX machine - the throughput of the null device. Machines with a fast /dev/null can discard unread mail, ignore uninteresting log messages and shred incoming user queries with efficient speed, thus leaving more time for harried system administrators to spend on important things like system upgrades and account deletions.
I intend to build a Really Useful Database of machines, operating systems, and the important benchmark time taken to execute:
This is the time taken to copy one million blocks of one kilobyte each from the zero device (a source of zeroes) to the null device (the death of bits, the bit bucket, the eater of words), and is, of course, the only true and genuine performance measure any sysadmin should ever care about. Being able to shred information at great speeds is what computers are primarily for, anyway. The observant will spot that in most cases, what this really measures is the performance of /dev/zero - producing reams of useless data is a much slower operation than destroying said data. However, as the purpose of this benchmark is to be a useless and meaningless benchmark, I figure that anything which can increase the uselessness of it has to be a good thing.
Hey, it's easy! Anybody can do it! Just log into your Unix machine, or any machine which looks like Unix, and execute the time dd command mentioned in the last section. Wait a while - anything from a few seconds to, er, a very long time in the case of slower machines. Eventually, it'll return something like:
1000000+0 records in 1000000+0 records out real 0m56.264s user 0m6.860s sys 0m47.470s
This is the time taken to execute the command - the real time elapsed, time spent in user mode, and time spent in the kernel Take the "real" entry and write it down, then fill in the form below and submit. Yes, my HTML's pretty bad, and my form design is even worse, but just think of it as being.. starkly functional, okay?
If you get funny results from this.. it's likely that your shell might have a "time" builtin that's being run rather than the system's "time" utility. I know the C shell does, and it's not unlikely that others might as well. Try running time with the full path (/bin/time or wherever) rather than just time", and this should have the desired effect.
To cite this benchmark, simply boast to everybody you meet that your machine has (for the example above) "56.264 Fhlushstones", and watch them bow down before the mighty data-destroying power of your hardware. Or whatever.
Please note - in seriousness, only run this if you know you're allowed to. It puts a certain amount of load on any machine, and you might annoy other users and, worse, your system administrators if you do it. I don't accept responsibility for damage caused, jobs lost, or anything nasty that happens if you run this command. Not that it's very probable that nasty things will happen, but you never know.
You can see the raw results right here, or the ordered results (slow, but working). The pattern is very obvious - Linux is very fast. Some people in the know have sent me mail explaining this - I'll add some information around here with the full story at some point. In summary, Linux may cheat slightly. Doesn't stop it being very fast at ignoring data, though.
Right here. Enjoy. If you have any interesting results or observations concerning this, ahem, benchmark, then let me know - address at the bottom of the page. Oh, and read the options before writing in something else - what you're looking for might well be in the picklist already. Sorting things is a pain if there are umpteen different "Other" for something that's in the picklist already.
Thanks to: The L-Space crowd for inspriring this ridiculousness, Rob Collier for some nifty sanity-checking code, and to Melissa Binde for pointing out that to be a real benchmark it should be "Fhlushstone", not "Flushstone"..