SCSI2SD v6 performance report

stormy

Member
Jun 23, 2019
86
35
18
@callahan FYI I was involved with beta testing the newer firmware as the older version would corrupt data on my apple 840av. When the latest firmware was finalised it did fix the corruption issue (the entire disc partition information would be erased on installing any application in system 8) but it had quite a negative impact on performance as you have found out here. It seems that you haven't had any corruption issues with your SGI systems though which is good.
 

stormy

Member
Jun 23, 2019
86
35
18
Here are some results of a 15k IBM SCSI disk vs the latest firmware of SCSI2SD V6 using the atto disk benchmark. The flat line at the bottom is the SD.
 

Attachments

  • Like
Reactions: Elf

aperezbios

New member
Dec 20, 2020
4
3
3
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...
Hi, I'm a little late to the party here, but the reason why SCSI2SD V6 has the read performance it has is largely attributable to its complete lack of read-ahead cache. The main microcontroller that powers the SCSI2SD V6 is an STM32F205 has _128 kilobytes of SRAM total_. Most Ultra160/Ultra320 SCSI drives have multiple megabytes of readahead cache (The ST3146707LW, chosen at random, has 8 megabytes of RAM. That's around 60,000 times more RAM. Off the top of my head, I have no idea what percentage of that program memory is occupied by the SCSI2SD V6 program, but presumably a significant portion of it, if not most of it, is continually in-use at any given time. Adding additional, external SRAM isn't possible, because there are nowhere near enough un-used pins on the microcontrollers.

Looking at the SCSI2SD V5, all variants of which are based on the Cypress PSoC 5LP (P/N CY8C5267AXI-LP051), which has a mere 32 kilobytes of SRAM, you see a similar limitation.

Of course, all of this could be solved by using a more powerful, more-expensive MCU with significantly more pins.
 
  • Like
Reactions: Elf

aperezbios

New member
Dec 20, 2020
4
3
3
And here is the faster SD performance on the old firmware
When you say "the old firmware" it would be much more helpful to explicitly cite the version you are/were testing with.

It doesn't appear any testing has been done with SCSI2SD V6 firmware version 6.3.2, which was released on October 27th of this year. According to Michael McMaster (the creator of SCSI2SD V5 and V6), here are the changes included in V6.3.2:
  • Increase limit of READ/WRITE BUFFER command for improved compatibility on SGI Irix hosts (emphasis is mine)
  • Add new config option to enable blind writes to improve SD card write performance. This was option was previously enabled default but causes problems with some SCSI hosts. This option must be disabled on 68K Macs if there are errors when writing data.
It's absolutely critical that you share the config settings AND firmware versions when sharing SCSI2SD benchmarks. Otherwise' they're far less useful to anyone else, because they're not necessarily reproducible.
 
  • Like
Reactions: Elf

Elf

Storybook
Feb 4, 2019
568
155
43
the reason why SCSI2SD V6 has the read performance it has is largely attributable to its complete lack of read-ahead cache
Interesting! And also good news about the firmware update :)

I sort of thought that given the read speeds of modern SD cards that as long as the RAM buffer was larger then a block (so that you're not trying to repeatedly read a block to send it out the SCSI side), it should still be able to read fast enough to saturate the 10mbyte/s SCSI-II bus.

I definitely understand why spinning disks would have a larger buffer given the seek times of the rotating disk as well as the opportunity to read ahead for sequential accesses while the SCSI bus is otherwise busy, but it still surprises me that this is a limiting factor for the SCSI2SD. Then again I can't claim to have really broken down where time is spent during an SD card read cycle.
 

stormy

Member
Jun 23, 2019
86
35
18
@aperezbios good point - the fast firmware which cause corruption on 68k hardware was 6.2.15. The fixed firmware, but much slower, was 6.3.0. Interestingly with 6.3.2 the option:
"Add new config option to enable blind writes to improve SD card write performance. This was option was previously enabled default but causes problems with some SCSI hosts. This option must be disabled on 68K Macs if there are errors when writing data."
Has been added. This fast writes is what was removed during my beta testing. I guess the option is safe on certain hardware and worth the risk. On my Quadra 840AV internal SCSI any writes would corrupt the entire partition with that enabled.
 

stormy

Member
Jun 23, 2019
86
35
18
My results from my Octane 2x400, SCSI2SDv6 rev F, firmware 6.4.11 / SD card used: Sandisk Ultra 64gb v10 80mb/s

SCSI-Util settings:
SCSI Terminator: ON
SCSI Speed Limit: Sync 10MB/s
Startup Delay: 0
SCSI Selection Delay: 255
Enable Parity: ON
Enable SCSI2 Mode: ON
(all other settings are default/off)

NOTE: To get the SCSI2SDv6 Rev F to work internally it required 5v molex power.

using diskperf settings by @callahan :
Code:
diskperf -W -D -n scsi2sdv6 -r4k -c 1G -t 10 /mnt/scsi2sd/tmpfile
Code:
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : scsi2sdv6
# Test date     : Tue Jul 13 09:29:40 2021
# Test machine  : IRIX64 OCTANE 6.5 07202013 IP30
# Test type     : XFS data subvolume
# Test path     : /mnt/scsi2sd/tmpfile
# Request sizes : min=4096 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)
#---------------------------------------------------------
       4096    2.29    4.00    0.96    4.02    1.07    2.71
       8192    3.93    5.72    1.82    5.69    2.18    4.19
      16384    5.00    7.20    3.27    7.19    3.17    5.86
      32768    6.18    8.25    0.34    8.27    0.16    7.32
      65536    5.41    8.80    0.57    8.88    0.06    8.32
     131072    3.72    7.80    0.48    9.29    0.09    8.96
     262144    2.62    9.52    1.17    9.52    0.35    9.36
     524288    5.80    9.20    2.15    9.19    0.60    9.08
    1048576    5.65    9.22    3.48    9.20    1.27    9.16
    2097152    4.94    9.23    3.76    9.21    2.08    9.19
    4194304    5.26    9.25    4.52    9.22    5.22    9.20
 
Last edited:
  • Like
Reactions: Elf

ghost180sx

Member
Dec 13, 2019
99
42
18
The Great White North
Stormy, those don't look like very impressive numbers, but the SCSI2SD card is limited to 10MB/s sync right? So actually for reads, you're getting close to max theoretical of the interface board which is nice.

Does the system feel faster? Do you use it for boot and daily use? Is there any way of measuring the sequential and random access seek times? Just curious...
 

stormy

Member
Jun 23, 2019
86
35
18
Stormy, those don't look like very impressive numbers, but the SCSI2SD card is limited to 10MB/s sync right? So actually for reads, you're getting close to max theoretical of the interface board which is nice.

Does the system feel faster? Do you use it for boot and daily use? Is there any way of measuring the sequential and random access seek times? Just curious...
Well they're like 10x better than what was going on in the first post. No I haven't used it as a system boot drive. I'm actually planning to use it in an Indigo2. Seek times are instantaneous as far as I know, the random read write speeds are there.
 

ghost180sx

Member
Dec 13, 2019
99
42
18
The Great White North
I just love how at blocks around 32k and up, you are virtually maxing out the 10mbit interface in all directions: forwards, backwards and random! Crazy!

It's not the 40mb/s that you can get with Ultra SCSI, but hey, that's gotta be fun to play with!
 
  • Like
Reactions: Elf

architeuthis

New member
Feb 25, 2021
7
5
3
For comparison: I just ran some performance tests with an ACARD SCSI to IDE adaptor (AEC-7720UW) plugged into a IDE-to-SATA adaptor, plugged into a 120 GB Kingston SSD on my R5k Indy.

The results look pretty good - I don't think it can get much better on a Fast-SCSI bus. Especially random reads - not surprisingly - perform pretty well.

Code:
indy 8% diskperf -W -n ACARD -c 1G -t 60 /tmp/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : ACARD
# Test date     : Wed Oct 20 12:54:34 2021
# Test machine  : IRIX indy 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    3.67    7.95    4.05    5.85    0.26    0.46
       8192    3.72    8.04    4.11    5.97    0.53    0.93
      16384    3.65    8.02    4.08    5.99    1.06    1.79
      32768    3.64    8.05    4.12    5.91    2.10    3.37
      65536    9.17    7.66    8.50    5.85    8.29    6.14
     131072    9.19    8.07    8.55    6.24    8.74    6.34
     262144    9.09    8.08    8.90    6.24    8.69    6.45
     524288    9.08    8.12    8.92    6.24    9.22    6.22
    1048576    9.15    8.14    9.05    7.11    9.13    4.23
    2097152    9.11    7.68    9.07    7.64    9.07    7.76
    4194304    9.07    7.66    9.13    7.65    9.16    7.60
 
  • Like
Reactions: Elf

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