OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Storage => Topic started by: Dariusz Piatkowski on December 20, 2020, 01:46:36 am
-
Hi Everyone,
I figured I'd take a stab at resolving the annoying issue with DISKIO not reporting correct throughput rates for the modern hardware, i.e. stuff like the fast SSD devices, etc.
Alright, so to that end, here is a DEBUG run for my SSD (Samsung 850 Evo - OK, I said "modern", yes, it's a few years old ;), but it's what pushed DISKIO over the edge on my box here):
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2283670 runs/sec
Hard disk 2: 255 sides, 30401 cylinders, 63 sectors per track = 238472 MB
Drive cache/bus transfer rate:
DEBUG => nData is: 1189762560
DEBUG => nTime is: 10260
115961 k/sec
Data transfer rate on cylinder 0 :
DEBUG => nData is: 3087028224
DEBUG => nTime is: 10264
300762 k/sec
Data transfer rate on cylinder 30399:
DEBUG => nData is: 2904620544
DEBUG => nTime is: 10244
283543 k/sec
CPU usage by full speed disk transfers: 23%
Average latency time:
DEBUG => nTime is: 10036.599360
DEBUG => nCnt is: 85352.196980
0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 121669 k/sec, 19% CPU usage
The stuff marked as "DEBUG => " is the raw data, if you're going to run this on your machine please report back the full output.
And here is the RETAIL output:
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2088687 runs/sec
Hard disk 2: 255 sides, 30401 cylinders, 63 sectors per track = 238472 MB
Drive cache/bus transfer rate: 118449 k/sec
Data transfer rate on cylinder 0 : 332803 k/sec
Data transfer rate on cylinder 30399: 302953 k/sec
CPU usage by full speed disk transfers: 23%
Average latency time: 0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 122717 k/sec, 23% CPU usage
As you can tell, the numbers are much better (no more overflow) and they for the most part jive with what I see in SysBench.
There are a few outstanding issues that I'm aware of:
1) this build is optimized for Pentium2, that's old stuff, I need to either remove or optimize for Pentium4, I just haven't looked up all the ICC flags & options, may be the reason why the Dhrystone value reported by this build is about 50% of what the official build has, not sure yet
2) the "Average data access time: Disk read error" is still here, this only fails on my SSD drive, I need to dig into the DosDevIOCtl API
3) "Drive cache/bus transfer rate:" shows a smaller rate than SysBench, not sure why that is, need to review further
4) RAMDISK numbers are still bad, or just flat out error out
ZIP attachment has two builds :
1) DEBUG - has the extra raw data dumps
2) RETAIL - if you just want an updated (hopefully correct) result and that's all you want
Feedback is welcome and appreciated!
-Dariusz
-
Hi Dariusz
I give it a quick try on a ArcaOS VM. The VM is running on a Win10 host with an SDD drive.
- Can it be possible to release it as 1.19? so it can not get confused with 1.18z
- Is it possible to share the source code to update the github repository? - once you produce the final release.
It seems to me that tthe program runs fine (diskio and debug)
But when I try to create an output file this way, I get this error?
[C:\HOME\DOWNLOADS\DISKIO_FIX_1]diskio-debug >debug.txt
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
Is there any other way you recommend you get the output file?
Regards
-
Hi Dariusz,
I gave the retail diskio a shot (diskio > diskio.txt) and got this:
DISKIO - Fixed Disk Benchmark, Version 1.18z
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
Number of fixed disks: 5
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 4009371 runs/sec
Hard disk 1: 255 sides, 60801 cylinders, 63 sectors per track = 476937 MB
Drive cache/bus transfer rate: 86400 k/sec
Data transfer rate on cylinder 0 : 277997 k/sec
Data transfer rate on cylinder 60799: 260108 k/sec
CPU usage by full speed disk transfers: 48%
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 138280 k/sec, 41% CPU usage
Hard disk 2: 255 sides, 60321 cylinders, 127 sectors per track = 953855 MB
Drive cache/bus transfer rate: -107190 k/sec
Data transfer rate on cylinder 0 : 185943 k/sec
Data transfer rate on cylinder 60319: 87011 k/sec
CPU usage by full speed disk transfers: 35%
Average latency time: 0.0 ms
Average data access time: 15.3 ms
Multithreaded disk I/O (4 threads): 45298 k/sec, 28% CPU usage
Hard disk 3: 255 sides, 650 cylinders, 63 sectors per track = 5098 MB
Drive cache/bus transfer rate: -142336 k/sec
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 648 : Disk read error.
CPU usage by full speed disk transfers: 93%
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): Disk read error.
-34014 k/sec, 64% CPU usage
Hard disk 4: 12 sides, 512 cylinders, 9 sectors per track = 27 MB
Drive cache/bus transfer rate: Disk read error.
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 510 :
____________________________________________________
It gave an error on the command line, I'm guessing because it detected 5 drives, but there are really only 3 (Disk 1 is an SSD, Disk 2 is a rotating hard drive, Disk 3 is a RAM drive) but the other 2 are possible USB drives. CDROMs there is only 1 (empty) and the other is also a possible USB drive. Not sure what to make of the results otherwise....
Regards,
-
Hi Martin,
...
- Can it be possible to release it as 1.19? so it can not get confused with 1.18z
- Is it possible to share the source code to update the github repository? - once you produce the final release.
Yes, absolutely. For now my focus is on getting as many samples of different hardware as possible. I suspect the really big drives (well, one should not think of a 1T that as being that big anymore...LOL, but David's example below still shows an issue there).
Once the little tweaks are behind us this is of course going out there. My changes are really tiny things, and quite honestly very simple changes from 'int' to 'long' or ULONG variables for the most part.
...
It seems to me that tthe program runs fine (diskio and debug)
But when I try to create an output file this way, I get this error?
[C:\HOME\DOWNLOADS\DISKIO_FIX_1]diskio-debug >debug.txt
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
Aha...so I wasn't getting this in my tests because I was individually testing just my SSD or HDD devices, but running it just like you did eventually produced the same result. What I found is the following in my POPUPLOG.OS2:
12-19-2020 20:49:36 SYS3184 PID 0819 TID 0001 Slot 0125
Y:\TMP\DISKIO.EXE
c000009b
00022182
EAX=00000000 EBX=00000000 ECX=000402ec EDX=00000000
ESI=00000090 EDI=00000090
DS=0053 DSACC=f0f3 DSLIM=ffffffff
ES=0053 ESACC=f0f3 ESLIM=ffffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:00022182 CSACC=f0df CSLIM=ffffffff
SS:ESP=0053:00092440 SSACC=f0f3 SSLIM=ffffffff
EBP=000924fc FLG=00210246
DISKIO.EXE 0002:00002182
...and SYS3184 is a "Divide by Zero".
Looking at where my output from DISKIO stopped it looks like the un-mounted USB removable drive is what caused the problem here. I'm running the DEBUG version right now to see the raw data but I'm sure that pesky 0 (zero) will show up.
In the meantime: thank you for the test and feedback!
-
Hi David,
...
Hard disk 2: 255 sides, 60321 cylinders, 127 sectors per track = 953855 MB
Drive cache/bus transfer rate: -107190 k/sec
Data transfer rate on cylinder 0 : 185943 k/sec
Data transfer rate on cylinder 60319: 87011 k/sec
CPU usage by full speed disk transfers: 35%
Average latency time: 0.0 ms
Average data access time: 15.3 ms
Multithreaded disk I/O (4 threads): 45298 k/sec, 28% CPU usage
Can you run the DEBUG version for this drive?
The 'cache/bus transfer rate' shows overflow and I'm curious what the raw counters actually are.
... It gave an error on the command line, I'm guessing because it detected 5 drives, but there are really only 3 (Drive C: is an SSD, Drive D: is a rotating hard drive, Drive Z: is a RAM drive) but the other 2 are possible USB drives. CDROMs there is only 1 (empty) and the other is also a possible USB drive. Not sure what to make of the results otherwise....
Yeah, I think this is the same issue Martin reported and which I was able to reproduce here. This happens when I run the full DISKIO and it kicks off a test for each storage device without me explicitly specifying which device it should be testing.
Truth be told changing the code to automatically exclude a USB drive (when it's not mounted) is probably beyond my OS/2 coding skillset...but I'll investigate it to learn a thing or two!
Much appreciate the feedback David! Thanks...
-
Hi, thanks for working on this. About optimization, i686 or Pentium II should be best for the vast majority of current CPU's.
Redirecting output seems to make the divide by zero crash worse here, which doesn't make it to the log. So I started up EPM, created a cmd shell and ran it in that.
Disk 1 is a fast 1TB drive on a SATA3 port, Disk 2 is the SSD on a SATA2 port, Disk 3 a regular HD on a SATA2 port, Disk 4 the ram disk, disk 5 is a USB stick, disk 6 is a 2TB external drive plugged into a USB2 port (like the stick). Note that the size of the 2TB is expressed as a negative. Really need to use 64bit variables I guess.
epm: H:\tmp >diskio
DISKIO - Fixed Disk Benchmark, Version 1.18z
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
Number of fixed disks: 12
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2778159 runs/sec
Hard disk 1: 255 sides, 60321 cylinders, 127 sectors per track = 953855 MB
Drive cache/bus transfer rate: -96336 k/sec
Data transfer rate on cylinder 0 : 178456 k/sec
Data transfer rate on cylinder 60319: 86168 k/sec
CPU usage by full speed disk transfers: 4%
Average latency time: 0.0 ms
Average data access time: 15.6 ms
Multithreaded disk I/O (4 threads): 45709 k/sec, 1% CPU usage
Hard disk 2: 255 sides, 29185 cylinders, 63 sectors per track = 228934 MB
Drive cache/bus transfer rate: 93543 k/sec
Data transfer rate on cylinder 0 : 123821 k/sec
Data transfer rate on cylinder 29183: 181134 k/sec
CPU usage by full speed disk transfers: 4%
Average latency time: 0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 52275 k/sec, 2% CPU usage
Hard disk 3: 255 sides, 30394 cylinders, 63 sectors per track = 238417 MB
Drive cache/bus transfer rate: 145126 k/sec
Data transfer rate on cylinder 0 : 91842 k/sec
Data transfer rate on cylinder 30392: 49640 k/sec
CPU usage by full speed disk transfers: 4%
Average latency time: 0.1 ms
Average data access time: 17.9 ms
Multithreaded disk I/O (4 threads): 20850 k/sec, 3% CPU usage
Hard disk 4: 255 sides, 1138 cylinders, 63 sectors per track = 8926 MB
Drive cache/bus transfer rate: 40175 k/sec
Data transfer rate on cylinder 0 : 20746 k/sec
Data transfer rate on cylinder 1136: 20531 k/sec
CPU usage by full speed disk transfers: 9%
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 20092 k/sec, 10% CPU usage
Hard disk 5: 255 sides, 985 cylinders, 63 sectors per track = 7726 MB
Drive cache/bus transfer rate: 18272 k/sec
Data transfer rate on cylinder 0 : 15544 k/sec
Data transfer rate on cylinder 983 : 16830 k/sec
CPU usage by full speed disk transfers: 1%
Average latency time: 1.9 ms
Average data access time: 1.8 ms
Multithreaded disk I/O (4 threads): 15958 k/sec, 1% CPU usage
Hard disk 6: 255 sides, 60085 cylinders, 255 sectors per track = -189423 MB
Drive cache/bus transfer rate: 21755 k/sec
Data transfer rate on cylinder 0 : 21658 k/sec
Data transfer rate on cylinder 60083: 21590 k/sec
CPU usage by full speed disk transfers: 1%
Average latency time: 1.8 ms
Average data access time: 20.3 ms
Multithreaded disk I/O (4 threads): 21787 k/sec, 2% CPU usage
Hard disk 7: 12 sides, 512 cylinders, 9 sectors per track = 27 MB
Drive cache/bus transfer rate: Disk read error.
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 510 : Disk read error.
CPU usage by full speed disk transfers: Disk read error.
Average latency time: Disk read error.
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads):
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
epm: H:\tmp >diskio-debug
DISKIO - Fixed Disk Benchmark, Version 1.18z
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
Number of fixed disks: 12
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2299450 runs/sec
Hard disk 1: 255 sides, 60321 cylinders, 127 sectors per track = 953855 MB
Drive cache/bus transfer rate:
DEBUG => nData is: 3407777792
DEBUG => nTime is: 10246
-86588 k/sec
Data transfer rate on cylinder 0 :
DEBUG => nData is: 1761370112
DEBUG => nTime is: 10259
171690 k/sec
Data transfer rate on cylinder 60319:
DEBUG => nData is: 889398272
DEBUG => nTime is: 10268
86618 k/sec
CPU usage by full speed disk transfers: 4%
Average latency time:
DEBUG => nTime is: 10019.599360
DEBUG => nCnt is: 135755.196980
0.0 ms
Average data access time:
DEBUG => nTime is: 10045.599344
DEBUG => nCnt is: 644.196980
15.5 ms
Multithreaded disk I/O (4 threads): 45620 k/sec, 1% CPU usage
Hard disk 2: 255 sides, 29185 cylinders, 63 sectors per track = 228934 MB
Drive cache/bus transfer rate:
DEBUG => nData is: 946132992
DEBUG => nTime is: 10242
92377 k/sec
Data transfer rate on cylinder 0 :
DEBUG => nData is: 1221276672
DEBUG => nTime is: 10240
119265 k/sec
Data transfer rate on cylinder 29183:
DEBUG => nData is: 1857397248
DEBUG => nTime is: 10253
181156 k/sec
CPU usage by full speed disk transfers: 5%
Average latency time:
DEBUG => nTime is: 10027.599360
DEBUG => nCnt is: 61825.196980
0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads):
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
-
Well, about the ramdisk.
All delays in it are produced by the i/o subsystem. The smarter i/o you use, the worse speed you get :)
Problem is that the fastest method is supported only by FAT and HPFS. JFS, HPFS386, FAT32 - all will fail with it (older FAT32 versions even cause a trap).
Try adding /1 to the HD4DISK command line and test the speed, especially when copying files to "nul" - this is the real value.
-
Dariusz,
Here are the results of diskio-debug -hd 2 > debug.txt:
DISKIO - Fixed Disk Benchmark, Version 1.18z
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
Number of fixed disks: 5
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 4117153 runs/sec
Hard disk 2: 255 sides, 60321 cylinders, 127 sectors per track = 953855 MB
Drive cache/bus transfer rate:
DEBUG => nData is: 3628144128
DEBUG => nTime is: 10250
-65055 k/sec
Data transfer rate on cylinder 0 :
DEBUG => nData is: 1905008128
DEBUG => nTime is: 10247
185908 k/sec
Data transfer rate on cylinder 60319:
DEBUG => nData is: 892714496
DEBUG => nTime is: 10256
87043 k/sec
CPU usage by full speed disk transfers: 3%
Average latency time:
DEBUG => nTime is: 10017.599360
DEBUG => nCnt is: 153431.196980
0.0 ms
Average data access time:
DEBUG => nTime is: 10008.599344
DEBUG => nCnt is: 655.196980
15.2 ms
Multithreaded disk I/O (4 threads): 45095 k/sec, 2% CPU usage
No error this time...
Regards,
-
Hi Martin,
...
- Can it be possible to release it as 1.19? so it can not get confused with 1.18z
- Is it possible to share the source code to update the github repository? - once you produce the final release.
Yes, absolutely. For now my focus is on getting as many samples of different hardware as possible. I suspect the really big drives (well, one should not think of a 1T that as being that big anymore...LOL, but David's example below still shows an issue there).
Once the little tweaks are behind us this is of course going out there. My changes are really tiny things, and quite honestly very simple changes from 'int' to 'long' or ULONG variables for the most part.
...
It seems to me that tthe program runs fine (diskio and debug)
But when I try to create an output file this way, I get this error?
[C:\HOME\DOWNLOADS\DISKIO_FIX_1]diskio-debug >debug.txt
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
Aha...so I wasn't getting this in my tests because I was individually testing just my SSD or HDD devices, but running it just like you did eventually produced the same result. What I found is the following in my POPUPLOG.OS2:
12-19-2020 20:49:36 SYS3184 PID 0819 TID 0001 Slot 0125
Y:\TMP\DISKIO.EXE
c000009b
00022182
EAX=00000000 EBX=00000000 ECX=000402ec EDX=00000000
ESI=00000090 EDI=00000090
DS=0053 DSACC=f0f3 DSLIM=ffffffff
ES=0053 ESACC=f0f3 ESLIM=ffffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:00022182 CSACC=f0df CSLIM=ffffffff
SS:ESP=0053:00092440 SSACC=f0f3 SSLIM=ffffffff
EBP=000924fc FLG=00210246
DISKIO.EXE 0002:00002182
...and SYS3184 is a "Divide by Zero".
Looking at where my output from DISKIO stopped it looks like the un-mounted USB removable drive is what caused the problem here. I'm running the DEBUG version right now to see the raw data but I'm sure that pesky 0 (zero) will show up.
In the meantime: thank you for the test and feedback!
I have the same error message.
[E:\]diskio-debug > debug.tx
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
My popup.log shows
12-20-2020 12:58:22 SYS3184 PID 005a TID 0001 Slot 00bc
E:\DISKIO-DEBUG.EXE
c000009b
000221a2
EAX=00000000 EBX=00000000 ECX=000402ec EDX=00000000
ESI=00000090 EDI=00000090
DS=0053 DSACC=d0f3 DSLIM=5fffffff
ES=0053 ESACC=d0f3 ESLIM=5fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:000221a2 CSACC=d0df CSLIM=5fffffff
SS:ESP=0053:00092440 SSACC=d0f3 SSLIM=5fffffff
EBP=000924fc FLG=00210246
DISKIO-DEBUG.EXE 0002:000021a2
I presently have no removable USB drive attached.
-
Hi David,
I have the same error message.
[E:\]diskio-debug > debug.tx
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
...
I presently have no removable USB drive attached.
Hmm, interesting...so another device is causing this as well.
Can you provide the output of the run that was created before the error occured? So basically whatever are the contents of the debug.tx that was created?
The last storage device that's logged is most likely where the issue occured...some early output should still be visible, such as: disk ID, sizing, preliminary cache/bus xfer rates (if successful, etc.).
BTW and/or FYI:
The previous version of DISKIO shows the same behaviour here, so point being: this is an existing issue which I'm going to try to chase down.
Thanks!
-
The text file contains no information. It is blank.
-
I'm curious everyone, does anyone actually want/need the Win32 version of the code?
It seems the whole logic is re-implemented twice in DISKIO, once for OS/2 and once for Win32, that also means the same variables, funcs and procs are defined twice, which generally just makes the whole thing a mess to keep up with.
I get the idea of main entry points being named the same, but I do not understand why the remaining codebase follows the same naming convention.
Anyways, I'm thinking of completely dropping the Win32 functionality and therefore changing the package to leave out the Win32 source as well, as such, will this cauase anyone a problem?
So I am far from understanding the stipulation with this particular codebase, can anyone advise if there is anything in here that necessitates the continuation of Win32 support? If so, I think I would need to fork my changes...is that generally how things get done?
I do not like the idea of forking it, but see no point to maintaining a dead codebase either.
Thanks!
-
Well, ideally would be to keep the Win32 codebase and binaries so people can do comparisons. Of course if you have no motivation to do that, you could remove them, while leaving them in history in case someone wants to resurrect them, and do a major version jump to ver 2 or fork by renaming your binary. You're the one taking on the maintainer-ship.
Hopefully you're using something like Git to maintain history.
BTW, which compiler are you using? I tried VACPP 3.08 with no joy, didn't even like the CPLUS type comments. It did build fine with OpenWatcom with this patch.
From a1cf054f2665f861b537300e70f183bb447b136c Mon Sep 17 00:00:00 2001
From: Dave Yeo <dave.r.yeo@gmail.com>
Date: Sun, 20 Dec 2020 16:42:12 -0800
Subject: [PATCH 2/2] Fix compilation on OpenWatcom This macro is declared in
the OW headers
---
sources/perfutil.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sources/perfutil.h b/sources/perfutil.h
index 9cb9800..238051b 100644
--- a/sources/perfutil.h
+++ b/sources/perfutil.h
@@ -57,11 +57,12 @@ typedef HOOKDATA * PHOOKDATA;
*
*/
-#define CMD_KI_RDCNT (0x63)
+#define CMD_KI_RDCNT 0x63
/* note: on SMP machine DosPerfSysCall() will return an array of */
/* CPUUTIL structures, by number of processors. */
-
+
+#ifndef __WATCOMC__
typedef struct _CPUUTIL
{
ULONG ulTimeLow; /* Low 32 bits of time stamp */
@@ -73,6 +74,7 @@ typedef struct _CPUUTIL
ULONG ulIntrLow; /* Low 32 bits of interrupt time */
ULONG ulIntrHigh; /* High 32 bits of interrupt time */
} CPUUTIL;
+#endif
typedef CPUUTIL *PCPUUTIL;
--
2.11.0
Tried a few things to find the divide by zero without luck and I'm not sure how to use the debugger in OW, I think I might have the HLL experimental linker screwing up wdw. Have to revisit.
Hmm, reviewing my patch, a related change got in, does VACPP need those brackets? OW didn't like them.
-
Hi
I have no interest for the Win32 version.
Regards
-
I tried VACPP 3.08 with no joy, didn't even like the CPLUS type comments.
BTW: No, that can't be the reason. "//" is defined in VAC 3.0.8 as single-line comment string, as well as C-Set/2 supports this.
-
You need to supply a compiler switch use use C++ comments in plain C code (.c files).
-
Ah yes, it's - Ss+ or /Ss+.
-
I tried VACPP 3.08 with no joy, didn't even like the CPLUS type comments.
BTW: No, that can't be the reason. "//" is defined in VAC 3.0.8 as single-line comment string, as well as C-Set/2 supports this.
Well, it sure complained. Here, I just added a CPLUS type comment on line 9 and get,
icc -q -Wpro -O -qtune=pentium2 -Gl -Gm -Gs -DOS2TMR -DOS2 -c cpuperf.c
warning EDC1020: Excess text tune=pentium2 ignored on /q option.
cpuperf.c(9:1) : error EDC0046: Syntax error.
cpuperf.c(9:4) : error EDC0166: Definition of function a requires parentheses.
...
Then problems like not knowing what __uint64 is, after I fixed the comments to be C type, so I switched to OW.
-
Hi Dave!
Well, ideally would be to keep the Win32 codebase and binaries so people can do comparisons. Of course if you have no motivation to do that, you could remove them, while leaving them in history in case someone wants to resurrect them, and do a major version jump to ver 2 or fork by renaming your binary.
Yeah, "ideally" is a great point to note. This was my initial thinking as well but given what I see as diminishing returns on preserving the Win32 stuff I will simply fork the non-Win32 login into a 2.00.00 release, which will be purse OS/2 only stuff.
...You're the one taking on the maintainer-ship.
Hopefully you're using something like Git to maintain history.
Well, my track record is spotty at best when it comes to 'wanting' and actually 'doing' - think FFMPEG from some years ago when you and I had a few conversation on this topic. My interest was in chasing down an audio artifact I was seeing in the current FFMPEG builds. Regardless, that issue was addressed by an updated build and so I never moved further along with my idea.
...BTW, which compiler are you using? I tried VACPP 3.08 with no joy, didn't even like the CPLUS type comments. It did build fine with OpenWatcom with this patch.
I've got VACPP 3.65 with FP2 installed here, so that is what's being used. I have transitioned to NMAKE32 as opposed to the old NMAKE, but that's only because VACPP moved that way so I figured I'd just settle on the latest release and run with it.
From a "problems encountered so far" side of things I can only think of two issues:
1) undefined variables in dhry_1.c: Int_1_Loc, Int_2_Loc, Int_3_Loc, etc.
Maybe I'm just misunderstanding how DISKIO is supposed to be built, but running the makefile causes everything to be compiled, and yet I kept on getting missing declarations for the variables in the DEBUG section of dhry_1.c, see the stuff in:
...
printf ("Execution ends\n");
printf ("\n");
#if 1
printf ("Final values of the variables used in the benchmark:\n");
printf ("\n");
printf ("Int_Glob: %d\n", Int_Glob);
...
Since some of these variables were defined in dhry_1.c and others were not, I simply added them to dhry_1.c. That caused my errors to go away, but the variables are not populated with any values during runtime, so something else is missing there.
2) INCLUDE directories and VACPP vs OS2_Toolkit vs GCC setups
On my machine I have all three installed.
Previously I was able to successfully compile stuff with just the VACPP environment enabled. But these were rather simplistic (my attempts at coding). This does not work for the bigger projects. So I needed to merge the VACPP & OS2_Toolkit stuff and exclude the GCC stuff that's sitting in /usr/include. That took a while to sort out, but that's not an issue with DISKIO, rather my own configuration.
Big part of this is that I rely on VisualSlickEdit as my IDE and the concept of PROJECTS. Each one can be defined as having it's own environment, so you can certainly build a VACPP project, a GCC project, etc, but all of these need to have the appropriate (and correct LOL) setups. I am totally expecting this effort though, but when you start with something new (such as DISKIO) it's hard to figure out what compile error is coming from a bad makefile, a bad source code, or a bad environment setup!!!
Therefore, what does work for me now is using the following environment setup to build with:
@ECHO OFF
SET CXXMAIN=G:\code\tools\Ibmcpp
SET TKMAIN=g:\code\tools\toolkit
SET GCCMAIN=g:\usr
SET INCLUDE=%TKMAIN%\H\ARPA;%TKMAIN%\H\NET;%TKMAIN%\H\NETINET;%TKMAIN%\H\NETNB;%TKMAIN%\H\RPC;%TKMAIN%\SPEECH\H;%TKMAIN%\H\GL;%TKMAIN%\H;%INCLUDE%
SET INCLUDE=%TKMAIN%\H\LIBC;%TKMAIN%\H\LIBC\SYS;%TKMAIN%\H\MACHINE;%TKMAIN%\H\PROTOCOL;%TKMAIN%\H\RPC;%TKMAIN%\H\STACK16;%TKMAIN%\H\SYS;%INCLUDE%
rem SET INCLUDE=%GCCMAIN%\INCLUDE;%INCLUDE%
rem ***********************************************************
rem IBM C and C++ Compilers for OS/2 environment variable settings
rem Licensed Materials - Property of IBM
rem (C) Copyright IBM Corp. 1991, 1997 All Rights Reserved
rem ***********************************************************
SET BEGINLIBPATH=%CXXMAIN%\DLL;%BEGINLIBPATH%
SET DPATH=%CXXMAIN%\HELP;%CXXMAIN%\LOCALE;%DPATH%
SET HELP=%CXXMAIN%\HELP;%HELP%
SET IPFC=%CXXMAIN%\BIN;%IPFC%
SET LIB=%CXXMAIN%\LIB;%LIB%
SET CPP_DBG_LANG=CPP
SET LANG=en_us
SET NLSPATHTEMP=%CXXMAIN%\MSG\%%N
SET NLSPATH=%NLSPATHTEMP%;%NLSPATH%
SET NLSPATHTEMP=
SET PATH=%CXXMAIN%\BIN;%PATH%
/* Kick off the NMAKE app */
g:\code\tools\toolkit\bin\nmake32.exe /a /f %1
exit
This is the result of the largely DEFAULT VACPP 3.65 install along with the grafted updates to the OS2_Toolkit that have been released by netlabs over the years.
-
OK, I should revisit the VACPP 3.08 setup, probably screwed up in adding the toolkit. BTW, Gnumake seemed to work here.
For OpenWatcom, I have this to set things up,
@echo off
echo Open Watcom Build Environment
SET WATCOM=g:\WATCOM
SET PATH=%WATCOM%\BINP;%WATCOM%\BINW;%PATH%
SET BEGINLIBPATH=%WATCOM%\BINP\DLL;%BEGINLINPATH%
SET INCLUDE=%WATCOM%\H;%WATCOM%\H\OS2;%INCLUDE%
SET LIB=%WATCOM%\lib386;%WATCOM%\lib386\os2;%LIB%
SET EDPATH=%WATCOM%\EDDAT
SET WIPFC=%WATCOM%\WIPFC
And running wmake -f Watcom.mak (after the above mentioned patch) produces this output,
Open Watcom Make Version 2.0beta1 Limited Availability
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
WCC386 -bm -bt=os2v2 -e60 -6r -i.\; -oabhiklmnrt -s -w5 -ze -zdp -zq -zfp -zgp -zp1 -d2 -dOS2TMR -dOS2 -fodiskio.obj diskio.c
diskio.c(378): Warning! W131: No prototype found for function '_endthread'
diskio.c(383): Warning! W202: Symbol 'nCnt' has been defined, but not referenced
diskio.c(383): Warning! W202: Symbol 'nTrack' has been defined, but not referenced
diskio.c(476): Warning! W131: No prototype found for function '_beginthread'
diskio.c(7): Warning! W202: Symbol 'rcsid' has been defined, but not referenced
diskio.c(125): Warning! W202: Symbol 'nSemCount' has been defined, but not referenced
WCC386 -bm -bt=os2v2 -e60 -6r -i.\; -oabhiklmnrt -s -w5 -ze -zdp -zq -zfp -zgp -zp1 -d2 -dOS2TMR -dOS2 -fodiskacc2.obj diskacc2.c
diskacc2.c(386): Warning! W202: Symbol 'status' has been defined, but not referenced
diskacc2.c(384): Warning! W202: Symbol 'i' has been defined, but not referenced
diskacc2.c(9): Warning! W202: Symbol 'rcsrev' has been defined, but not referenced
diskacc2.c(7): Warning! W202: Symbol 'rcsid' has been defined, but not referenced
WCC386 -bm -bt=os2v2 -e60 -6r -i.\; -oabhiklmnrt -s -w5 -ze -zdp -zq -zfp -zgp -zp1 -d2 -dOS2TMR -dOS2 -fodhry_1.obj dhry_1.c
dhry_1.c(153): Warning! W131: No prototype found for function 'Func_2'
dhry_1.c(159): Warning! W131: No prototype found for function 'Proc_7'
dhry_1.c(164): Warning! W131: No prototype found for function 'Proc_8'
dhry_1.c(173): Warning! W131: No prototype found for function 'Proc_6'
WCC386 -bm -bt=os2v2 -e60 -6r -i.\; -oabhiklmnrt -s -w5 -ze -zdp -zq -zfp -zgp -zp1 -d2 -dOS2TMR -dOS2 -fodhry_2.obj dhry_2.c
dhry_2.c(39): Warning! W131: No prototype found for function 'Func_3'
WCC386 -bm -bt=os2v2 -e60 -6r -i.\; -oabhiklmnrt -s -w5 -ze -zdp -zq -zfp -zgp -zp1 -d2 -dOS2TMR -dOS2 -focpuperf.obj cpuperf.c
WLINK form os2 lx option int, dosseg, map, eliminate, mang, tog sort global @diskio.def
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited Availability
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating map file
creating an OS/2 linear extended executable
No show stopping warnings. I did adjust the flags a bit trying to produce a debug build but it didn't change the warnings.
I have run into what seems like a major OS/2 bug. If I have my USB3 HD plugged into my USB C adapter and try to run diskio (and sysbench), the system locks up hard while benchmarking the first or second hard drive, the USB one is number 5 or 6. This is repeatable.
Interestingly I tried it with the 1 TB JFS partition marked dirty after the crash and it worked though the USB 3 drive seemed to give USB 2 speeds, about 22 MB/s whereas copying an ISO I see 90+ MB/s.
Probably worth opening an issue at some point.
-
This is a reposting of my message to AN Testers from today.
epm: {0}[I:\Download\sysutil\diskio] diskio
DISKIO - Fixed Disk Benchmark, Version 1.20
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
2020 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: 5716722 runs/sec
Hard disk 1: 255 sides, 29185 cylinders, 63 sectors per track = 228934 MB
Drive cache/bus transfer rate: 106195 k/sec
Data transfer rate on cylinder 0 : 146183 k/sec
Data transfer rate on cylinder 29183: 191315 k/sec
CPU usage by full speed disk transfers: 11%
Average latency time: 0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads):
133148 k/sec, 9% CPU usage
Hard disk 2: 12 sides, 512 cylinders, 9 sectors per track = 27 MB
Drive cache/bus transfer rate: Disk read error.
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 510 : Disk read error.
CPU usage by full speed disk transfers: Disk read error.
Average latency time: Disk read error.
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads):
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
epm: {99}[I:\Download\sysutil\diskio]
Hard disk 1 is a relative old SSD: A (partly faulty) Kingston
SKC 300 S37A (240 GB).
Haven't tried with the faster Samsung 860 EVO (500 GB) so far.
Hard disk 2 doesn't exist.
This seems to give better values for SSDs than Sysbench.
-
Does it have a sense to do diskbench on SSD with not aligned partition ?
-
Diskio reads tracks and ignores partitions and file systems. Along with the rest of OS/2, it does expect 512 byte sectors but i doubt that matters.
-
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 (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.
Caveats
1) 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.
-
Hello Dariusz
My test:
[D:\]cd D:\diskio125
[D:\diskio125]diskio
DISKIO - Fixed Disk Benchmark, Version 1.25
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
2020-2024 Dariusz Piatkowski
Number of fixed disks: 10
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 3307018 runs/sec
Hard disk 1: 255 sides, 14593 cylinders, 63 sectors per track = 114470 MB
Drive cache/bus transfer rate: 101023 k/sec
Data transfer rate on cylinder 0 : 116343 k/sec
Data transfer rate on cylinder 14591 : 241957 k/sec
CPU usage by full speed disk transfers: 0%
Average latency time: 0.1 ms
Average data access time: 0.1 ms
Multithreaded disk I/O
1 thread: 116510 k/sec, 0% CPU usage
2 threads: 109296 k/sec, 0% CPU usage
3 threads: 108393 k/sec, 0% CPU usage
4 threads: 108952 k/sec, 0% CPU usage
5 threads: 109710 k/sec, 0% CPU usage
6 threads: 110312 k/sec, 0% CPU usage
7 threads: 110657 k/sec, 0% CPU usage
8 threads: 110428 k/sec, 0% CPU usage
Hard disk 2: 255 sides, 61769 cylinders, 127 sectors per track = 976752 MB
Drive cache/bus transfer rate: 165832 k/sec
Data transfer rate on cylinder 0 : 404224 k/sec
Data transfer rate on cylinder 61767 : 407399 k/sec
CPU usage by full speed disk transfers: 0%
Average latency time: 0.0 ms
Average data access time: 0.2 ms
Multithreaded disk I/O
1 thread: 170925 k/sec, 0% CPU usage
2 threads: 161234 k/sec, 0% CPU usage
3 threads: 158390 k/sec, 0% CPU usage
4 threads: 158535 k/sec, 0% CPU usage
5 threads: 158018 k/sec, 0% CPU usage
6 threads: 158656 k/sec, 0% CPU usage
7 threads: 156967 k/sec, 0% CPU usage
8 threads: 157459 k/sec, 0% CPU usage
Hard disk 3: 12 sides, 512 cylinders, 9 sectors per track = 27 MB
Drive cache/bus transfer rate: Disk read error.
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 510 : Disk read error.
CPU usage by full speed disk transfers: Disk read error.
Average latency time: Disk read error.
Average data access time: Disk read error.
Multithreaded disk I/O
1 thread: Disk read error.
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
[D:\diskio125]
popuplog.os2
12-16-2024 18:45:31 SYS3184 PID 0054 TID 0001 Slot 0086
D:\DISKIO125\DISKIO.EXE
c000009b
0002258d
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000
DS=0053 DSACC=d0f3 DSLIM=bfffffff
ES=0053 ESACC=d0f3 ESLIM=bfffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:0002258d CSACC=d0df CSLIM=bfffffff
SS:ESP=0053:000b3878 SSACC=d0f3 SSLIM=bfffffff
EBP=000b389c FLG=00210246
DISKIO.EXE 0002:0000258d
Disk1 is win10, disk2 is Arcaos
Saludos
-
Hello Roberto!
Thank you for testing and the feedback.
My test:
[D:\diskio125]diskio
DISKIO - Fixed Disk Benchmark, Version 1.25
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 3307018 runs/sec
Hmm, seems like low CPU score, what are you running? If that's a fast CPU I think we may be getting an overflow in the benchmark code, on my TO-DO list.
Hard disk 1: 255 sides, 14593 cylinders, 63 sectors per track = 114470 MB
Drive cache/bus transfer rate: 101023 k/sec
Data transfer rate on cylinder 0 : 116343 k/sec
Data transfer rate on cylinder 14591 : 241957 k/sec
CPU usage by full speed disk transfers: 0%
Average latency time: 0.1 ms
Average data access time: 0.1 ms
Multithreaded disk I/O
1 thread: 116510 k/sec, 0% CPU usage
2 threads: 109296 k/sec, 0% CPU usage
3 threads: 108393 k/sec, 0% CPU usage
4 threads: 108952 k/sec, 0% CPU usage
5 threads: 109710 k/sec, 0% CPU usage
6 threads: 110312 k/sec, 0% CPU usage
7 threads: 110657 k/sec, 0% CPU usage
8 threads: 110428 k/sec, 0% CPU usage
So CPU is an 8-core chip, yes?
Interesting that its showing '0% CPU usage', I mean great, but that just seem like maybe we have a side-effect of showing whole numbers only and no decimal places for the 'CPU Usage'.
Can you get me a debug-run on just that drive please?
Hard disk 3: 12 sides, 512 cylinders, 9 sectors per track = 27 MB
Drive cache/bus transfer rate: Disk read error.
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 510 : Disk read error.
CPU usage by full speed disk transfers: Disk read error.
Average latency time: Disk read error.
Average data access time: Disk read error.
Multithreaded disk I/O
1 thread: Disk read error.
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
Yup, USB devices...I am looking at ways of checking whether the storage devices that are identified by DISKIO at the start are actually usable, before the attempt to benchmark them actually starts.
-
Hi Dariusz, I get results more like Roberto, though it usually doesn't get as far here before crashing,
DISKIO - Fixed Disk Benchmark, Version 1.25
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
2020-2024 Dariusz Piatkowski
Number of fixed disks: 16
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 148719 runs/sec
Hard disk 1: 255 sides, 60801 cylinders, 63 sectors per track = 476937 MB
Drive cache/bus transfer rate: 166465 k/sec
Data transfer rate on cylinder 0 : 332980 k/sec
Data transfer rate on cylinder 60799 : 331016 k/sec
CPU usage by full speed disk transfers: 8%
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O
1 thread:
is logged and then
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
The debug build exits here after the CPU benchmark, which varies widely on a quiet system and once locked the computer hard.
This is a I5-7500@3.5Ghz with Nvme and SSD drives.
Perhaps a SMP issue?
Running the original also crashes,
DISKIO - Fixed Disk Benchmark, Version 1.18z
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
Number of fixed disks: 16
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 7461002 runs/sec
Hard disk 1: 255 sides, 60801 cylinders, 63 sectors per track = 476937 MB
Drive cache/bus transfer rate: 150517 k/sec
Data transfer rate on cylinder 0 : -155262 k/sec
Data transfer rate on cylinder 60799: -144451 k/sec
CPU usage by full speed disk transfers: 44%
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
An earlier build from you got further,
DISKIO - Fixed Disk Benchmark, Version 1.20
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
2020 Dariusz Piatkowski
Number of fixed disks: 16
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 8660078 runs/sec
Hard disk 1: 255 sides, 60801 cylinders, 63 sectors per track = 476937 MB
Drive cache/bus transfer rate: 146900 k/sec
Data transfer rate on cylinder 0 : 285680 k/sec
Data transfer rate on cylinder 60799: 287686 k/sec
CPU usage by full speed disk transfers: 50%
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads):
221010 k/sec, 46% CPU usage
Hard disk 2: 255 sides, 583 cylinders, 63 sectors per track = 4573 MB
Drive cache/bus transfer rate: 24411 k/sec
Data transfer rate on cylinder 0 : 22839 k/sec
Data transfer rate on cylinder 581 : 19798 k/sec
CPU usage by full speed disk transfers: 48%
Average latency time: 0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads):
24381 k/sec, 50% CPU usage
Hard disk 3: 255 sides, 60322 cylinders, 127 sectors per track = 953871 MB
Drive cache/bus transfer rate: 39907 k/sec
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 60320: 433087 k/sec
CPU usage by full speed disk transfers: Disk read error.
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): Disk read error.
40497 k/sec, 62% CPU usage
Hard disk 4: 255 sides, 60322 cylinders, 127 sectors per track = 953871 MB
Drive cache/bus transfer rate: 48704 k/sec
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 60320: 610275 k/sec
CPU usage by full speed disk transfers: Disk read error.
Average latency time:
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
There's entries in popuplog.os2 for each crash.
-
I remembered that you don't run AcpiDaemon, so I killed it and retested, got further before crashing. Then tried without redirecting stdout, stderr (diskio 2>&1 | tee diskio.log) and it finished, of course the results scrolled off the screen
Even doing "diskio > diskio.log" crashes as above.
Running without AcpiDaemon here also sees the CPU temp at about 65C compared to 38C with it running and testing diskio.
-
Number of fixed disks: 17
Number of CD-ROM drives: 1
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: -567273196 runs/sec
Hard disk 1: 255 sides, 62261 cylinders, 63 sectors per track = 488390 MB
Drive cache/bus transfer rate:
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
Even if it didn't crash with a "divide by zero" error (009B), 'Diskio' would be unlikely to provide useful info about my disks. Both of them are GPT and are normally *hidden* from the system by 'gpt.flt'.
What OS/2 sees are a bunch of _emulated_ MBR disks, one for each mounted partition plus a few spares that appear to be unpartitioned. Doing a speed test on a phony disk that refers to some partition somewhere on one of the physical disks wouldn't be overly informative. In any case, I don't think you can access them using the Physical Disk IOCTLs that 'Diskio' depends on, so we'll probably never know.
FWIW... GPT disks can be made visible, though I'm not sure how accessible they are. I look forward to trying 'Diskio' again with the disks visible once the current crop of issues is resolved.
-
Even if it didn't crash with a "divide by zero" error (009B), 'Diskio' would be unlikely to provide useful info about my disks. Both of them are GPT and are normally *hidden* from the system by 'gpt.flt'.
What OS/2 sees are a bunch of _emulated_ MBR disks, one for each mounted partition plus a few spares that appear to be unpartitioned. Doing a speed test on a phony disk that refers to some partition somewhere on one of the physical disks wouldn't be overly informative. In any case, I don't think you can access them using the Physical Disk IOCTLs that 'Diskio' depends on, so we'll probably never know.
FWIW... GPT disks can be made visible, though I'm not sure how accessible they are. I look forward to trying 'Diskio' again with the disks visible once the current crop of issues is resolved.
Seems to kind of work on GPT disk here, each partition presents as a device the full size of the device, eg for my 1TB NVMe
Hard disk 3: 255 sides, 60322 cylinders, 127 sectors per track = 953871 MB
Drive cache/bus transfer rate: 137487 k/sec
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 60320 : 71482 k/sec
CPU usage by full speed disk transfers: Disk read error.
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O
1 thread: 6654 k/sec, 28% CPU usage
2 threads: 762685 k/sec, 28% CPU usage
3 threads: Disk read error.
896092 k/sec, 20% CPU usage
4 threads: Disk read error.
1889132 k/sec, 26% CPU usage
Hard disk 4: 255 sides, 60322 cylinders, 127 sectors per track = 953871 MB
Drive cache/bus transfer rate: 148253 k/sec
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 60320 : 32923 k/sec
CPU usage by full speed disk transfers: Disk read error.
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O
1 thread: Disk read error.
158947 k/sec, 35% CPU usage
2 threads: Disk read error.
166172 k/sec, 35% CPU usage
3 threads: Disk read error.
156057 k/sec, 35% CPU usage
4 threads: Disk read error.
162560 k/sec, 34% CPU usage
Hard disk 5: 255 sides, 60322 cylinders, 127 sectors per track = 953871 MB
Drive cache/bus transfer rate: 149314 k/sec
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 60320 :
The external process was cancelled by a Ctrl+Break or another process.
First try locked up the machine so I did CTRL-C when I had enough info. The numbers are quite a bit worse then the MBR SSD along with the Disk read errors which seem to vary.
-
Hmm, seems like low CPU score, what are you running? If that's a fast CPU I think we may be getting an overflow in the benchmark code, on my TO-DO list.
This is a old laptop hp8760w with xeon
So CPU is an 8-core chip, yes?
Yes
Can you get me a debug-run on just that drive please?
This disk1 is a 1tb sdd, but show 114470mb
DISKIO - Fixed Disk Benchmark, Version 1.25
(C) 1994-1998 Kai Uwe Rommel
(C) 2004 madded2
2020-2024 Dariusz Piatkowski
Number of fixed disks: 10
Number of CD-ROM drives: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 3308172 runs/sec
DEBUG => using DosPhysicalDisk for $1:
DEBUG => found the disk...
DEBUG => sectors is : 63
DEBUG => tracks is : 14593
DEBUG => sides is : 255
DEBUG => sector is : 512
Hard disk 1: 255 sides, 14593 cylinders, 63 sectors per track = 114470 MB
Drive cache/bus transfer rate: 101216 k/sec
DEBUG => nSector is: 512
DEBUG => nSectors is: 63
DEBUG => nData is: 521773056
DEBUG => nTime is: 5155
Data transfer rate on cylinder 0 : 115738 k/sec
DEBUG => nData is: 594897408
DEBUG => nTime is: 5140
Data transfer rate on cylinder 14591 : 241781 k/sec
DEBUG => nData is: 1239372288
DEBUG => nTime is: 5126
CPU usage by full speed disk transfers: 0%
Average latency time: 0.1 ms
DEBUG => nTime is: 1
DEBUG => nCnt is: 33782
Average data access time: 0.1 ms
DEBUG => nTime is: 1
DEBUG => nCnt is: 37410
Multithreaded disk I/O
1 thread: 116244 k/sec, 0% CPU usage
DEBUG => nTotal is: 596800512
DEBUG => nTime is: 5134
2 threads: 109120 k/sec, 0% CPU usage
DEBUG => nTotal is: 559351296
DEBUG => nTime is: 5126
3 threads: 108347 k/sec, 0% CPU usage
DEBUG => nTotal is: 556254720
DEBUG => nTime is: 5134
4 threads: 109145 k/sec, 0% CPU usage
DEBUG => nTotal is: 560899584
DEBUG => nTime is: 5139
5 threads: 108745 k/sec, 0% CPU usage
DEBUG => nTotal is: 560254464
DEBUG => nTime is: 5152
6 threads: 111054 k/sec, 0% CPU usage
DEBUG => nTotal is: 571931136
DEBUG => nTime is: 5150
7 threads: 111081 k/sec, 0% CPU usage
DEBUG => nTotal is: 571737600
DEBUG => nTime is: 5147
8 threads: 110371 k/sec, 0% CPU usage
DEBUG => nTotal is: 566318592
DEBUG => nTime is: 5131
Yup, USB devices...I am looking at ways of checking whether the storage devices that are identified by DISKIO at the start are actually usable, before the attempt to benchmark them actually starts.
The disk3 is no disk, no usb conected.
Saludos
-
Hello
Subsequently, I now present you with DISKIO v1.25 (http://darcio.no-ip.org/os2/diskio/diskio-v1.25-Dec_2024.zip (http://darcio.no-ip.org/os2/diskio/diskio-v1.25-Dec_2024.zip)),
Just to be part of the fun, I also wanted to test it out.
I tried it here on a VirtualBox ArcaOS 5.1 Guest machine running on a Windows 10 host.
I run diskio.exe >out.txt
It has:
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: 2
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 6045508 runs/sec
Hard disk 1: 255 sides, 5221 cylinders, 63 sectors per track = 40954 MB
Drive cache/bus transfer rate: 92707 k/sec
Data transfer rate on cylinder 0 : 54160 k/sec
Data transfer rate on cylinder 5219 : 313296 k/sec
CPU usage by full speed disk transfers: 12%
Average latency time: 0.2 ms
Average data access time: 0.8 ms
Multithreaded disk I/O
1 thread: 41534 k/sec, 11% CPU usage
Hard disk 2: 12 sides, 512 cylinders, 9 sectors per track = 27 MB
Drive cache/bus transfer rate: Disk read error.
Data transfer rate on cylinder 0 : Disk read error.
Data transfer rate on cylinder 510 : Disk read error.
CPU usage by full speed disk transfers: Disk read error.
Average latency time: Disk read error.
Average data access time: Disk read error.
Multithreaded disk I/O
1 thread:
and it gave me this error:
SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 009B.
I will try it on real hardware later.
Regards