@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.
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.
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.
Edit: With apologies, I no longer wish to have involvement with SGUG or SGI communities in general,
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.
This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.
and have also chosen to remove all of my content. Many things have changed since I co-founded, named, and ultimately
then left SGUG. There are many good people around, to whom I apologize for frustrating by removing these things, and
also many petty people that over the years whittled down both the enjoyment as well as sense of obligation I used to
feel to anyone else regarding what was ultimately just a hobby. Unfortunately one of the latter now writes the rules
and so it is time for me to take my things and go.
This message will replace all of my previous forum posts because deleting threads that I started would have removed
other peoples' posts.
Last edited:
@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.
"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.
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 :
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:
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...
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.
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.
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
Adding in some more data points.
First, the best marks:
Indigo2 and RASCSI
-1g was taking so long, set it for 128M, I will run the G overnight.
RASCSI info:
d8824e3596535ceda46a83744e01615872de2cb2 Linux rascsi1 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux
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.26Indigo2 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.17RASCSI info:
d8824e3596535ceda46a83744e01615872de2cb2 Linux rascsi1 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux
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?
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?