SCSI2SD v6 performance report

23jodys

New member
Dec 15, 2019
1
2
3
The host: a R5K/180 Indy.

Note: the Indy and scsi2sd required a terminator on the external scsi port. I don't normally leave one there, but the system would hang and crash without it.

The adapter: SCSI2SD v6.

SCSI2 turned on. Parity turned on. Set to 10MB/sync. 2GB allocated in the scsi2sd-util. FYI, you definitely need to have an SD card inserted for anything to work.

The SD card: Sandisk Extreme 128GB (this is A2 rated which is supposed to help with small random reads/writes)

The results.

Code:
# diskperf -W -n scsi2sd_10M_Sync -c 1G -t 60 /mnt/testpath                                   
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : scsi2sd_10M_Sync
# Test date     : Sat Dec 14 12:20:45 2019
# Test machine  : IRIX isengard 6.5 10070055 IP22
# Test type     : XFS data subvolume
# Test path     : /mnt/testpath
# Request sizes : min=4096 max=4194304
# Parameters    : direct=0 time=60 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
       4096    1.26    3.31    1.41    3.28    0.09    0.15
       8192    1.38    3.61    1.27    3.13    0.17    0.29
      16384    1.41    3.61    1.28    3.14    0.34    0.59
      32768    1.38    3.62    1.28    3.14    0.68    1.12
      65536    4.46    1.19    3.60    3.84    2.99    1.47
     131072    4.48    1.57    3.47    3.93    2.61    2.34
     262144    4.49    1.93    3.20    3.69    3.39    1.88
     524288    4.49    2.15    2.95    3.51    2.98    2.19
    1048576    4.50    2.19    2.94    3.47    3.24    1.20
Dismal. Comparatively there is a 300GB/10K drive that does this on the same bus (not at the same time of course)

Code:
# diskperf -W -n 300G_10K_SGI_Indy -c 128M -t 10 /tmp/testpath                               
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : 300G_10K_SGI_Indy
# Test date     : Sat Dec 14 13:53:04 2019
# Test machine  : IRIX isengard 6.5 10070055 IP22
# Test type     : XFS data subvolume
# Test path     : /tmp/testpath
# Request sizes : min=4096 max=4194304
# Parameters    : direct=0 time=10 scale=1.000 delay=0.000
# XFS file size : 134217728 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
       4096   16.22   13.13   15.82    4.09    0.01   17.52
       8192   17.00    1.30   13.63    5.66    0.00   20.44
      16384   13.77   13.41   20.61    4.20    0.76   24.40
      32768   14.03   13.44   21.23    4.25    2.12   24.35
      65536   15.78   12.97   17.80    4.08    1.26   28.79
     131072   16.84   13.27   17.07    3.18   12.16   27.01
     262144   13.70   11.72   16.02    4.54   17.24   25.63
     524288   12.88   15.86   16.86    5.83   14.97   24.19
    1048576   14.46   12.13   15.55   10.01   11.39   23.87
    2097152   14.23   12.73   16.99   11.34   13.97   24.01
    4194304   14.07   10.86   13.46   14.61   16.69   18.73
Conclusion: I will probably have to deal with the noise.
 
  • Like
Reactions: callahan and Elf

Elf

Storybook
Feb 4, 2019
307
72
28
Interesting; I had always assumed that with the updated v6 design (no longer using SPI mode to write to the SD card) the limiting factor was the 10MB/s SCSI-II bus. I wonder where the bottleneck is?
 

stormy

Member
Jun 23, 2019
32
12
8
Could you please list the firmware version of the scsi2sd v6, there have been quite a few updates in the last few months. There may have been some improvements.
 

nintendoeats

New member
Mar 9, 2020
12
9
3
Montreal, Canada
I ran the same test, and my results are ~2x better on average (some are around the same, some are almost 4x). I have done no experimentation to see how I might maximize performance, these are just some settings that work. Playing with these settings is something that I want to do soon.

While I did use an external terminator for this test, my system works fine without one when when using SCSI2SD. I did need to use a slightly older firmware to work with my system, which is mentioned somewhere on the SCSI2SD website. 6.3.0 might work, but I haven't installed it yet.

System: Indy R4400SC/150 - 128MB RAM - XL24 - SCS2SD v6
SD card: SanDisk 128GB Extreme Pro SDXC UHS-I/U3 V30 (SDSDXXY-128G-GN4IN)
Firmware: 6.2.5
Settings:

settings1.PNG

settings2.PNG


Code:
# diskperf -W -n scsi2sd_redux -c 1G -t 60 /tmp/testpath                             
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : scsi2sd_redux
# Test date     : Thu APR  3 21:10:13 2020
# Test machine  : IRIX IRIS 6.5 10070055 IP22
# Test type     : XFS data subvolume
# Test path     : /tmp/testpath
# Request sizes : min=4096 max=4194304
# Parameters    : direct=0 time=60 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
       4096    2.84    5.96    2.64    4.27    0.18    0.35
       8192    2.52    5.54    2.72    4.56    0.34    0.70
      16384    2.74    6.11    2.85    4.59    0.63    1.38
      32768    2.76    6.06    2.83    4.73    1.31    2.56
      65536    5.92    5.25    5.43    4.27    4.36    4.91
     131072    5.00    5.86    5.44    4.87    4.13    5.79
     262144    5.57    6.67    5.58    5.51    4.85    5.91
     524288    5.49    6.98    5.48    5.49    5.34    5.89
    1048576    5.73    7.16    5.66    6.22    4.52    4.07
    2097152    5.54    6.65    5.59    6.42    4.69    7.42
    4194304    5.58    6.76    5.72    6.59    5.39    6.19
 
Last edited:

nintendoeats

New member
Mar 9, 2020
12
9
3
Montreal, Canada
I have been trying to get results with SCSI 2 enabled. I'm finding there is a lot of run-to-run variance. I'm guessing this is because the SD card is basically a mini-computer with a mind of its own. Enabling SCSI2 was generally faster (over 1MB/s sometimes), but no specific operation was consistent across a few runs.
 
Last edited:
  • Like
Reactions: Elf

Elf

Storybook
Feb 4, 2019
307
72
28
Interesting results; I wonder how much the performance varies by SD card. Random write being so slow until the block size gets bigger sort of suggests big block sizes internal to the card. I wonder why random reads are so slow on smaller block sizes though...
 

callahan

Member
Jul 20, 2019
36
23
8
TL;DR: After further tests, 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.

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 64GB 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.

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, at best it performed on par with the Fujitsu and, at worst (large file write performance), had less than half the measured throughput.

Sequential read/write test results (average of two runs, using the forward test results only; backward tests showed the same trends):
SCSI2SD Sequential Read_Write Performance.png


Random read/write test results (average of two runs):
SCSI2SD Random Reaad_Write Performance.png


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 at best 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​

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 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>
Note that I did not/not try a newer firmware version primarily because it was a giant pain to get the SCSI2SD working with my Indy originally, so I do not want to risk messing anything up.
 

nintendoeats

New member
Mar 9, 2020
12
9
3
Montreal, Canada
Thank you for running such a comprehensive suite of tests! They are certainly consistent with my experience; that running off the SCSI2SD is not noticeably slow. The one difference, I have successfully run my SCSI2SD with another device on the bus (though I cannot recall if it was with multiple devices on the internal connector).
 
  • Like
Reactions: callahan

callahan

Member
Jul 20, 2019
36
23
8
My Indy has been very particular. Initially the SCSI2SD wouldn't work at all ... After a bunch of troubleshooting I found that a 6 second startup delay somehow fixes the issue. There might be some odd timing issue with my SCSI2SD or Indy that causes compatibility problems. I've tried both known-good SGI OEM (IBM produced IIRC) 50 pin drives and known-good Fujitsu drives using the external and internal connectors with no luck. It's a limitation I've grown to live with.
 

Elf

Storybook
Feb 4, 2019
307
72
28
After further tests, 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.
A very thorough examination, thank you! :)

I wonder why the SCSI2SD suffers in sequential read performance? It seems like it shouldn't be the case...
 
  • Like
Reactions: callahan

nintendoeats

New member
Mar 9, 2020
12
9
3
Montreal, Canada
I wonder why the SCSI2SD suffers in sequential read performance? It seems like it shouldn't be the case...
I wish it was easier to seperate the SCSI2SD from the controller on the SD card. I speculate that it has more to do with the card than the SCSI2SD bridge, since I would think that from the bridge's perspective there is no difference between random and sequential reads/writes.
 
Last edited:
  • Like
Reactions: Elf

callahan

Member
Jul 20, 2019
36
23
8
Yeah, my results are definitely slower than @nintendoeats . Could be slightly older firmware or a slower-performing SD card.

Also worth noting that sequential performance was substantially better than random performance, so it didn't suffer relative to itself (no surprise that the UW-160 spinny drive could saturate the Fast SCSI bus).
 
  • Like
Reactions: Elf

nintendoeats

New member
Mar 9, 2020
12
9
3
Montreal, Canada
THE SAGA CONTINUES.

I'm installing IRIX 6.5 on an Indigo2 R4400/250. I didn't have any spare good SD cards, so I grabbed a random Lexar class 10 MicroSD. The installation has been running for 5 hours.

Clearly, the quality of your SD card is very important. Since it's past 11:00 and rqsall is still at 37%, diskperf will have to wait until tomorrow. Clearly I won't be using this installation very much, holy jimminy. I...have another SD card coming...
 
Last edited:

nintendoeats

New member
Mar 9, 2020
12
9
3
Montreal, Canada
Boot time, measured from the end of "System is coming up" screen to the Toolchest appearing, is 6:11. Yeesh. This is on a completely default install.

My Indigo2 is essentially unusable with this card. Sometimes things load quickly, but usually not. For example, at one point it took 20 seconds to open the shell.

Here are my diskperf results:

System: Indigo2 R4400SC/250 - 192MB RAM - GR3 (Elan) - SCS2SD v6
SD card: Some old 32GB class 10 Lexar microSD
Firmware and settings unchanged from my last test (except for disk size and SCSI2 turned on)

Code:
# diskperf -W -n scsi2sd_BadCard -c 1G -t 60 /tmp/testpath                       
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : scsi2sd_BadCard
# Test date     : Tue Apr  7 08:15:16 2020
# Test machine  : IRIX IRIS 6.5 05190003 IP22
# Test type     : XFS data subvolume
# Test path     : /tmp/testpath
# Request sizes : min=4096 max=4194304
# Parameters    : direct=0 time=60 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
       4096    1.96    8.36    1.71    7.02    0.02    0.25
       8192    2.53    6.40    2.53    5.02    0.04    0.84
      16384    2.56    5.57    2.53    5.10    0.08    1.80
      32768    2.66    6.50    2.54    4.56    0.27    0.12
      65536    6.20    6.06    1.98    0.00    0.80    0.00
     131072    5.37    6.31    2.24    2.67    0.79    1.78
     262144    6.86    6.70    1.99    2.24    0.61    2.89
     524288    5.59    5.85    2.29    0.01    0.79    5.60
    1048576    5.58    5.40    2.17    0.02    0.75    3.84
    2097152    6.69    5.33    2.37    1.68    0.90    7.48
    4194304    6.18    6.52    2.26    3.26    2.23    0.18
Many of those numbers aren't that different from those of my good SD card. However, the random reads and writes are truly appalling. They are also inconsistent across sizes, which I'm guessing represents strong run-to-run variance based on the behavior of the card's internal controller.

Combine this information with the results from @callahan and the disk tests from @23jodys , and I think we can conjecture that random read/write performance is critical to real-world performance of system boot and running typical applications. I don't think this is news to anybody, but it seems like for general use you should stick with whatever has the best small random r/w performance (within reason). In the tests so far, that is a SCSI2SD with a high-quality SD card (even if it can't touch the spinning metal for forward and large size r/w performance).

Another thing to consider is endurance. I'm curious if performance will degrade faster for SD cards than it does for typical SCSI HDDs, since SD cards tend to use lower-quality flash. Le sigh, if only those SATA -> SCSI bridges weren't being sold at horrifically inflated prices...
 
Last edited:
  • Like
Reactions: Elf

Elf

Storybook
Feb 4, 2019
307
72
28
I'm curious if performance will degrade faster for SD cards than it does for typical SCSI HDDs, since SD cards tend to use lower-quality flash.
I used to worry about this while putting together single board systems that ran off Compact Flash cards, but, if you do the math on it some pretty consistent throughput has to be put on it for many months / a few years to get to the write cycle life of the individual cells. If you can find write cycle life info for those cards it's worth doing the math vs. IOPS and see what you come up with for your conbination.
 
  • Like
Reactions: nintendoeats

callahan

Member
Jul 20, 2019
36
23
8
I also have an Indigo2 (R10k 175MHz) and Octane that I've been running benchmarks against. Will post results when I have good data. Initial results look like the I2 is substantially faster all-around than the Indy, wonder if it's just a better SCSI controller?


FWIW, the Octane is spitting nonsensical data with the diskperf options I had been using (rnd_rd in the 100+ MB/S range, other values 0.00). After looking at the manpage and examples, I think we need to add the "-D" flag. Just starting a run now, but it seems to be giving good data even with a 10 second run on my Octane. If this options gives better data, I'll re-run it on all three systems.

One reason I chose my Transcend card is that I seem to recall it's supposed to have increased write tolerance. Shame that the SCSI2SD almost certainly has no write-leveling feature.

On the bogus data, initial phases of a few different runs ...

Code:
[octane]:~/indy$ diskperf -W -n Octane_SCSI2SD -c 1G -t 60 /home/indy/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : Octane_SCSI2SD
# Test date     : Mon Apr  6 21:11:10 2020
# Test machine  : IRIX64 octane 6.5 07202013 IP30
# Test type     : XFS data subvolume
# Test path     : /home/indy/testpath
# Request sizes : min=16384 max=4194304
# Parameters    : direct=0 time=60 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
      16384    9.83    5.95    5.96    0.00    0.00  140.21
That doesn't make sense! Let's see if -D w/ 10 sec tests is consistent for a couple runs ...

Code:
[octane]:~/indy$ diskperf -W -D -n Octane_SCSI2SD -c 1G -t 10 /home/indy/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : Octane_SCSI2SD
# Test date     : Tue Apr  7 21:11:14 2020
# Test machine  : IRIX64 octane 6.5 07202013 IP30
# Test type     : XFS data subvolume
# Test path     : /home/indy/testpath
# Request sizes : min=16384 max=4194304
# Parameters    : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
      16384    1.41    6.32    1.43    6.52    1.19    5.65
^C
[octane]:~/indy$ diskperf -W -D -n Octane_SCSI2SD -c 1G -t 10 /home/indy/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : Octane_SCSI2SD
# Test date     : Tue Apr  7 21:19:15 2020
# Test machine  : IRIX64 octane 6.5 07202013 IP30
# Test type     : XFS data subvolume
# Test path     : /home/indy/testpath
# Request sizes : min=16384 max=4194304
# Parameters    : direct=1 time=10 scale=1.000 delay=0.000
# XFS file size : 1073741824 bytes
#---------------------------------------------------------
# req_size  fwd_wt  fwd_rd  bwd_wt  bwd_rd  rnd_wt  rnd_rd
#  (bytes)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)  (MB/s)
#---------------------------------------------------------
      16384    1.42    6.33    1.42    6.55    1.19    5.65
      32768    1.93    7.43    1.93    7.70    1.75    6.97
Much better ! The most consistent SCSI2SD data I've seen, with only 10s intervals!
 
Last edited:

callahan

Member
Jul 20, 2019
36
23
8
UPDATE:

It turns out my last post's methodology wasn't great. So, updates!

New TL;DR: With top-tier SD cards the SCSI2SD v6 can perform better than conventional 10k and 15k RPM disks on a Fast SCSI (10MB/S) bus, except for sequential write. The quality of your SD card is very important to overall performance. Also, firmware 6.1.3 performs better (on tested SGI systems) than 6.3.0.


This update is driven by two developments. First, after getting some nonsense data from my Octane over the last week, I realized that it is critical to use the -D flag with SGI's diskperf utility. Using this flag removed variability with 10 second runs on the Indy and Indigo2 and kept my Octane from giving nonsensical results (e.g. random read speeds of >250 MB/S). Second, I bought a new top-tier SD card to compare SCSI2SD performance. The results surprised me!

Methodology notes:

I used two high-performance SD cards with identical drive images, SCSI2SD settings, and firmware.

  1. Transcend S64GSDC500S 64GB (amazon link), currently ~$25. This is a good card, U3/V30 rated, listed transfer rates of up to 95 MB/s Read; 60 MB/s write. Tests with this card are sometimes shorthanded as $testsystem_T
  2. Sandisk Extreme Pro SDSDXXY-128G-GN4IN 128GB (amazon link), current ~$38. This is a top-tier card, also U3/V30 rated but claims "Shot speeds up to 90MB/s, transfer speeds up to 170MB/s". Tests with this card are sometimes shorthanded as $testsystem_San

Note: Both of these are very good SD cards. If you use a more normal/bargain SD card, I would expect worse--possibly very bad--performance using the SCSI2SD.

All diskperf tests used the following command line (and relied on previously created 1GB test files): diskperf -W -D -n [description] -r4k -t 10 [$testpath]. All tests were performed with a single user logged in via ssh. The systems tested were:
  1. SGI Indy, 180Mhz R5000 processor, 256MB RAM, IRIX 6.5.22. On this device, each test was performed with only the test drive connected (i.e. the test drive was the system and test disk).
  2. SGI Indigo2, 175MHz R10000 processor, 640MB RAM, IRIX 6.5.22. On this device, each test was performed on the secondary SCSI controller and the test device was the only device on the bus.
  3. SGI Octane, 2x360MHz R12000 processors, 1.5GB RAM, IRIX 6.5.30. On this device 50/68 pin drives were connected externally to the secondary SCSI controller. 80 pin drives were connected internally. The Fujitsu MAX drive was the booted/system drive for all tests (including the test of the MAX drive itself).

The drives tested were:
  1. SCSI2SD v6, Firmware 6.1.3, Transced 64GB SD card
  2. SCSI2SD v6, Firmware 6.1.3 and Firmware 6.3.0, Sandisk Extreme Pro 128GB SD card
  3. Fujitsu MAJ3182MP 18.2GB 10k RPM UW-160 disk
  4. Fujitsu MAX-series 36GB 15k RPM U320 disk
  5. HP 3008B26C 300GB 15k RPM U320 disk

I've attached graphs to this post comparing sequential and random read/write tests for all drives. My key takeaways:
  1. The SCSI2SD/Sandisk duo was fast at random reads/writes (should be no surprise). It outperformed even the 15k RPM U320 drives in the Octane at random read performance up until 32kb blocks (where the conventional drives were able to surpass the SCSI2SD's Fast SCSI transfer limit). On the Indy/Indigo2, it outperformed all drives at all block sizes.
  2. The only clear loss for the SCSI2SD against other Fast SCSI devices was in sequential write performance, where it topped out around 4 MB/S while the 10k and 15k RPM disks were able to sustain transfers at the Fast SCSI bus limit.
  3. The older 6.1.3 firmware outperformed the newest 6.3.0 release handily. I tested both with and without "turbo mode" enabled. I found turbo slightly increased most speeds, but also added variability that caused a drops at some block sizes. I've reverted my device to 6.1.3, no-turbo. My SCSI2SD config is still available on my github.
  4. Using a SCSI2SD on a Indy/Indigo2 appears to be largely a no-brainier -- minus cost. At ~$140 for SCSI2SD v6+SD card, my current SCSI2SD setup is over twice as expensive as all of the other disks I tested combined (each was less than $20 on ebay).
  5. On anything with a Ultra/Wide SCSI bus, the SCSI2SD probably won't make sense except for a very specific use cases (e.g. CD-ROM emulation).
RandRead.JPGRandWrite.JPGSeqRead.JPGSeqWrite.JPG

SD card/firmware comparison:
SDcomp_Random.JPGSDcomp_sequential.JPG

Not a key takeway, but I was surprised that the SCSI2SD performed measurably better on the Octane, despite being limited to Fast SCSI speeds, which both the Indy and Indigo2 support. Any ideas why?

I also repeated the real-world benchmarks with the new Sandisk card and added Octane results for comparison. My key takeaway remains that in real-world tests, the performance boost with a SCSI2SD was nearly enough to make a top-spec Indy feel like a high-spec Indigo2. Emphasis on the "feel" and "nearly". Obviously it doesn't make up for the difference in raw CPU or graphics muscle. And in some workloads, the sequential write performance will still make a SCSI2SD slower than an Indy with a good conventional disk. I've attached graphs with times for various tasks. A few further methodology notes:
  1. The Indy and Indgo2's IRIX installs are configured very similarly, but they are not identical. The Octane has a newer IRIX version and more software installed.
  2. As before, boot time was measured from the first text on miniroot window to the visual login screen.
  3. As before, Firefox (current nekoware version) was measured from the command to a fully rendered Google.com.
Realworld.JPG

That's it for now!
 
  • Like
Reactions: Jacques and Elf

Elf

Storybook
Feb 4, 2019
307
72
28
Very nice data; thanks for coming back with that update :)

I have been going the 15kRPM disk route but it sounds like I should pick up some more SCSI2SDs...
 
  • Like
Reactions: callahan

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu