UPDATE!

========
Allow me to pontificate here for a little first as that will properly set the context of the DISKIO upgrade.
I've recently 'upgraded' to a new'er CPU - LOL, seriously, from 6-core AMD Phenom II X6 to 8-core AMD FX-8370, which being a hardware "let's have fun" kind of a guy is now massively overclocked to 5GHz and happily churning away!
Anyways, I was expecting to gain some performance and as it turned out the various benchmark scores across the board were higher. However strangely enough (and I still haven't figured this one out yet, although I suspect it's the chipset difference - 890FXA vs 990FXA) my HD xfer rates actually took a bit of a dive.
Sooo...out came the DISKIO source and I picked up where we left off last time.
Subsequently, I now present you with DISKIO v1.25 (
http://darcio.no-ip.org/os2/diskio/diskio-v1.25-Dec_2024.zip), the changes are:
* Revision 1.25 2024/12/13 13:20:393 dspiatkowski
* - implemented some code visual clean-up and re-organization
* - introduced the stepped multi-thread benchmark from 1 to MAXTHREAD = CPUCOUNT
* - introduced the optional user defined test duration, DEFAULT=5 secs
In short, I attempted to close out some of the loose ends we had last time around, although I suspect there are at least a few more places that I need to re-visit, so expect to see some errors with very fast systems.
Further on, DISKIO in it's multithreaded test had a static define of 4-threads...I thought to myself: well, OK, but if I am genuinely assessing the capability of my system I would want to maximize what it can do. So on SMP machines where more than 4 CPU cores are available it would make sense that I might want to run multiple disk threads beyond just the 4 that DISKIO currently defines.
I therefore re-wrote the multithreaded logic to test from THREAD=1 to THREAD=maxcpu.
That gives you a bit of a "how scalable is my machine" kind of an assessment as you observe the throughput rates shift when multiple threads start running concurrently.
Outside of this, I found that the default 'test duration' of 10 secs was causing us some problems in the past (again, on very fast machines), and so I had previously dropped that to 5 secs, but to be honest while that's an OK default I should not be telling YOU how long to run a test for, that should be YOUR decision.
So there is an extra parameter now, see '-t x' where the 'x' is the duration of the test, so '-t 10' would run all the tests for 10 secs.
Caveats1) I am finding that with my RAMDISK I still occasionally see "Disk read error" (see sample output below) so I suspect I have some variable overflow somewhere in there as the RAMDISK setup is very fast, as one would expect it to be.
2) The USB attached storage devices, which previously caused some problems will continue to do so. I did not include any logic to deal with a device that is reporting itself as a storage device and yet has no actual storage media loaded/attached. (to-do list)
3) The Dhrystone CPU benchmark needs updates to deal with fast CPUs. (to-do list)
Here is a sample run for my RAMDISK and Evo 850 SSD storage devices:
[G:\CODE\source\os2\diskio]diskio -hd 1 2 -t 1
DISKIO - Fixed Disk Benchmark, Version 1.25
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
2020-2024 Dariusz Piatkowski
Number of fixed disks: 9
Number of CD-ROM drives: 1
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 6813001 runs/sec
Hard disk 1: 255 sides, 1142 cylinders, 63 sectors per track = 8958 MB
Drive cache/bus transfer rate: 669608 k/sec
Data transfer rate on cylinder 0 : 640079 k/sec
Data transfer rate on cylinder 1140 : 639079 k/sec
CPU usage by full speed disk transfers: 15%
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O
1 thread: 635049 k/sec, 14% CPU usage
2 threads: 268509 k/sec, 7% CPU usage
3 threads: 506938 k/sec, 14% CPU usage
4 threads: 572116 k/sec, 17% CPU usage
5 threads: 473047 k/sec, 15% CPU usage
6 threads: 476042 k/sec, 20% CPU usage
7 threads: 527724 k/sec, 30% CPU usage
8 threads: 452431 k/sec, 33% CPU usage
Hard disk 2: 255 sides, 30401 cylinders, 63 sectors per track = 238472 MB
Drive cache/bus transfer rate: 128555 k/sec
Data transfer rate on cylinder 0 : 264076 k/sec
Data transfer rate on cylinder 30399 : 239458 k/sec
CPU usage by full speed disk transfers: 6%
Average latency time: 0.1 ms
Average data access time: 0.1 ms
Multithreaded disk I/O
1 thread: 112556 k/sec, 3% CPU usage
2 threads: 111679 k/sec, 2% CPU usage
3 threads: 108675 k/sec, 4% CPU usage
4 threads: 107708 k/sec, 3% CPU usage
5 threads: 107778 k/sec, 3% CPU usage
6 threads: 107738 k/sec, 4% CPU usage
7 threads: 107084 k/sec, 4% CPU usage
8 threads: 107028 k/sec, 6% CPU usage
Concurrent full speed reads on 2 hard disks
Combined throughput: 666164 k/sec, 22% CPU usage
The ZIP file has the standard and DEBUG versions. As before, if you are seeing funny stuff from the standard build, run the DEBUG, capture the outputs and send it my way please.