SCSI2SD v6 performance report

stormy

Active member
Jun 23, 2019
123
46
28
@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

Active member
Jun 23, 2019
123
46
28
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
718
209
43
Western United States
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

Active member
Jun 23, 2019
123
46
28
@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

Active member
Jun 23, 2019
123
46
28
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

Active member
Dec 13, 2019
107
45
28
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

Active member
Jun 23, 2019
123
46
28
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

Active member
Dec 13, 2019
107
45
28
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
6
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: seclorum and Elf

massiverobot

irix detailer
Feb 8, 2019
116
98
28
Philly
twitter.com
Adding in some more data points.

First, the best marks:

Code:
dillera@fuel ~ $ diskperf -W -D -n fuel-u320 -c 1G -t 10 /tmp/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : fuel-u320
# Test date     : Fri Jun 12 00:16:27 1998
# Test machine  : IRIX64 fuel 6.5 07202013 IP35
# Test type     : XFS data subvolume
# Test path     : /tmp/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    3.97   73.01    4.23   10.18    4.45    5.01
      32768    7.72   97.39    8.71   21.55    8.74    9.43
      65536   14.62  118.02   18.62   29.40   15.98   16.58
     131072   26.28  130.44   42.97   43.21   28.55   26.98
     262144   43.87  133.80   43.10   43.46   46.42   39.01
     524288   65.74  134.09   64.03   52.06   68.11   50.93
    1048576   87.84  134.34   84.62   64.50   87.59   59.46
    2097152  105.31  134.42   85.09   86.09   87.99   85.24
    4194304  110.21  129.39  101.38  106.50  103.72  106.26

Indigo2 and RASCSI
-1g was taking so long, set it for 128M, I will run the G overnight.


Code:
indigo2 48# diskperf -W -D -n rascsi-pi4 -c 128M -t 10 /usr2/testpath
#---------------------------------------------------------
# Disk Performance Test Results Generated By Diskperf V1.2
#
# Test name     : rascsi-pi4
# Test date     : Sun Feb  7 15:21:43 1999
# Test machine  : IRIX indigo2 6.5 10070055 IP22
# Test type     : XFS data subvolume
# Test path     : /usr2/testpath
# Request sizes : min=4096 max=4194304
# Parameters    : direct=1 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    0.83    0.98    0.87    0.97    0.51    0.55
       8192    0.93    1.08    0.94    1.07    0.68    0.76
      16384    0.97    1.13    0.98    1.12    0.83    0.94
      32768    0.99    1.16    0.99    1.15    0.93    1.06
      65536    1.00    1.17    1.00    1.15    0.96    1.10
     131072    1.00    1.17    1.00    1.16    0.98    1.14
     262144    1.00    1.17    1.00    1.17    1.00    1.16
     524288    1.00    1.18    1.00    1.17    1.00    1.17
    1048576    1.01    1.17    0.99    1.17    1.00    1.17
    2097152    1.00    1.17    1.00    1.18    1.00    1.17
    4194304    1.00    1.18    1.00    1.17    1.00    1.17
RASCSI info:



d8824e3596535ceda46a83744e01615872de2cb2 Linux rascsi1 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux
 
  • Like
Reactions: seclorum and Elf

seclorum

New member
Sep 14, 2022
5
3
3
Vienna, Austria
This is a very interesting thread - thanks for all the hard work to research the details and for sharing a good assessment of the situation.

I'm using SCSI2SD not just for my SGI gear, but also other systems too - Yamaha A-samplers, Powerbook, a couple other retro-computing items too boring to mention - so I have an interest in the SCSI2SD firmware, from the perspective of 'how does it work' and 'can it be optimized' somehow.

I see a lot of use of unlikely() / __builtin_expect throughout the code, which raises a bit of alarm bell. Its just a little too judicious. So .. I want to set up to build the SCSI2SD firmwares ..

Does anyone else have a working build of the SCSI2SD Firmware, meanwhile?
 

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