Kahenraz wrote on 2022-11-19, 12:43:

I'm having problems with speedsys causing my system to spontaneously reboot, especially when paired with UDMA and disk caching d […]
Show full quote

I'm having problems with speedsys causing my system to spontaneously reboot, especially when paired with UDMA and disk caching drivers. I'm also getting this error on my second disk:

SpeedSys and "Divide overflow"

I would also like to see write performance, which speedsys doesn't appear to do.

What other alternatives are there to speedsys for disk benchmarking?

I am using speedsys on a fresh install of FreeDOS 1.3. I can't find a way to get it stable, despite trying several different methods of XMS memory and other drivers.

I haven't tried this but maybe it would work for you?

https://www.lo-tech.co.uk/wiki/DOS_Disk_Tester

According to my experiences on faster systems Rayer's rawspeed.exe is more reliable to measure sustained disk throughput.
http://rayer.g6.cz/programm/rawspeed.exe

If you want to test e.g. reading/writing 20MB you should set it as argument (default is 250 MB):
rawspeed.exe 20

I get 50MB/s write, 40MB/s with rawspeed and 86MB/s write, 62MB/s read with disktest. Both tests were done with a 250MB file.

I wonder what the cause of the difference is.

Kahenraz wrote on 2022-11-20, 11:13:

I get 50MB/s write, 40MB/s with rawspeed and 86MB/s write, 62MB/s read with disktest. Both tests were done with a 250MB file.

I wonder what the cause of the difference is.

From the disktest wiki

File System Performance and Caching The utility tests file system, rather than raw device performance. Hence, the results will b […]
Show full quote

File System Performance and Caching
The utility tests file system, rather than raw device performance. Hence, the results will be greatly influenced by disk caching and file system overhead.

DOS doesn't keep the entire FAT in memory (since DOS 2) and therefore with no caching the drive will be continually seeking to the FAT as well as the data areas. Caching of such structures in DOS, prior to SMARTDRV, is achieved with the CONFIG.SYS BUFFERS statement.

In general, to minimse the impact of FAT seeks:

For FAT-12 volumes, ensure at least 16 buffers are allocated (BUFFERS=16 in CONFIG.SYS)
For FAT-16 volumes, ensure the maximum 99 buffers are allocated.
Random throughput is also highly skewed by the relationship between the test file size and the FAT allocation unit size, presumably due to the computational overhead of following the FAT to ultimately calculate disk block addresses. This impact is dramatic on slow processors: on an PC/XT running a test on a compact-flash card with a 4MB test file, sector IOPS rates vary from 60 IOPS (2GB partition) to 14 IOPS (60MB partition).

That explains a lot. Thank you.