Edit -- Some of this was wrong. See updated benchmarks in my reply below.
TL;DR: After testing, I've found that SCSI2SD v6's max performance is slower than a high-end 10,000RPM SCSI drive, but it still often outperforms such drives in normal usage on an SGI Indy.
Based on discussions here and elsewhere, I decided to do some benchmarks using my own hardware. My test system:
SGI Indy, 180Mhz R5K, 256MB RAM
Two identically imaged drives with Irix 6.5.22 and a smattering of Nekoware and demos (each drive was tested when it was the only drive on the bus, primarily because I can't get my SCSI2SD to work with another drive.)
-- SCSI2SD v6 w/ Transcend high performance SD card. More on my SCSI2SD settings below.
-- Fujitsu MAJ3182MP UW-160 10,000RPM SCSI disk (68 pin interface w/ a 68-50 pin adapter).
First, I benchmarked both drives using diskperf 1.2. I found that the 10 second test interval produced wildly varying and often nonsensical results (near zero throughput or throughput nearly twice the theoretical maximum speed of the Indy's Fast SCSI bus), so in the end I used 60 second test intervals. Note this is 60 seconds per test (i.e. 60 seconds for 4MB forward write, 60 seconds for 4MB forward read, etc.), so a complete test suite takes ~75 minutes. I ran each test twice on each drive. The two test runs gave very similar results (minus a couple of outliers on the SCSI2SD data), with 1-sigma values generally less than .2MB/S.
Below I've attached graphs with the following diskperf test results:- Sequential read/write test results (average of two runs, using the forward test results only; backward tests showed the same trends), and
- Random read/write test results (average of two runs)
These results showed that at best, the SCSI2SD performed roughly on par with the Fujitsu control, especially with read/writes less than 64kb. With larger files, it still sometimes performed on par with the Fujitsu but, at worst (large file write performance), had less than half the measured throughput.
Next, I performed a suite of three tests representing real-world use cases. These results found, in contrast to the above, that performance with the SCSI2SD was better than the Fujitsu in every day applications. I repeated the first two test series twice, again values from the tests matched nicely. I only performed the tar tests once per drive.
Test 1: System boot-up (time from the first text displayed on the mini-root to the visual login window)
- SCSI2SD: 44 seconds
- Fujitsu: 51 seconds
Test 2: Firefox loading (from open command to complete rendering of
www.google.com)
- SCSI2SD: 37 seconds
- Fujitsu: 52 seconds
Note: Tests 1 and 2 are obviously read-heavy (avoiding the SCSI2SD's greatest flaw according to diskperf), but I still did not expect it to do so well based on the neck and neck read performance from the diskperf tests.
Test 3A/B: tar and untar a large set of files of varying, but mostly small, size (I used /usr/nekoware on the tested system, test tar was ~489MB. I did not/not use the verbose option)
3A: Archive
- SCSI2SD: 6 minutes, 10 seconds
- Fujitsu: 3 minutes, 54 seconds
3B: Extract
- SCSI2SD: 11 minutes, 24 seconds
- Fujitsu: 4 minutes, 43 seconds
Note: These results seem to confirm the diskperf results, showing a large performance difference when writing large files.
After seeing this data, I will continue to use my SCSI2SD as my "everyday" Indy drive. It performs better than a spinning disk in the tasks I perform the most often, uses much less power, and is quieter. However, if your workload includes many operations with large sets of files, a conventional disk may be considerably faster (but then, why on earth are you using a system/device with only a Fast SCSI bus?).
More on my SCSI2SD config:
Firmware 6.2.1, excerpts from my config. xml (My full SCSI2SD config xml file is available on
my github)
Code:
<parity>true</parity>
<enableScsi2>true</enableScsi2>
<selLatch>true</selLatch>
<startupDelay>6</startupDelay>
<scsiSpeed>0</scsiSpeed>
