pshipkov wrote on 2024-03-30, 18:47:

@douglar
If your question was towards me - no software drivers needed for all ISA SCSI controllers i touched so far, including the AHA-1542 noted above.

The original poster was doing tests under windows 95, so I figured a SCSI driver was involved.

p.s. If you are testing under DOS&BIOS, I guess the question would be what ROM version is on your SCSI card? You probably have the ROM shadowed too, but it's always important to check that too.

Hi all. I used the win95r2 built in drivers. From my experience these are most convinient for older hardware. Bios was 2.02 or so if I remember correctly

Rom address was definitely shadowed @ D400

Also surprised that you could bench your scsi drives with speedsys. Mine wasn’t detected there no matter what config (in bios, aspi driver y/n, etc). It simpl wasn’t selectable. Same for nusi8 and others. 4speed was the only one.

Again: double CPU speed. Double ISA clock. Fastest devices available. — Nearly same max ide bandwidth results. strange to me

I also read here in the past that ide cards are just more or less interface cards without logic. So there shouldn’t be a performance difference between them (except cache ones)

Marco wrote on 2024-03-31, 08:32:

Also surprised that you could bench your scsi drives with speedsys. Mine wasn’t detected there no matter what config (in bios, aspi driver y/n, etc). It simpl wasn’t selectable. Same for nusi8 and others. 4speed was the only one.

My experience with caching IDE controllers & SCSI controllers is that some work with speedsys and others don’t. I imagine it has something to do with the bios int implementation but I don’t know exactly what.

Seems like you are using the right driver. I wanted to make sure that the card wasn’t in compatibility mode, using real mode INT 13 calls.

There is a newer BIOS available for that card. http://vogonsdrivers.com/getfile.php?fileid=552 Couldn’t hurt to try that out if you have an prom burner.

This is interesting because all SCSI and IDE devices show up synthetic test apps like SpeedSys and Coretest, for me at least.
But i have a vague memory of System Info 8 missing one SCSI adapter - so far the only case, so i remembered it.

As for the significantly different system parameters resulting in small local storage perf improvements:
- processors don't matter. Most of the time they sit on their hands waiting. You can see how AMD 386DX and IBM BL3 are basically on par.
- processor frequency multipliers don't matter. 386DX @50MHz produces very similar results as IBM BL3 @100MHz (2x50).
- ISA bus frequency and wait states is what matters.
Btw, same applies to Am5x86-133 @160 (4x40) and P24T @100 (2.5x40), for example. And so on.

Agree. Regarding the last bullet: again that’s why I wonder why with double isa clock (25MHz) you only get 4000kb instead of my 3500kb with 13 MHz clock. Maybe we run into the pio 0/1 limit instead of isa limit. Or is this bypassed by XTIDE?

Marco wrote on 2024-04-01, 18:18:

Agree. Regarding the last bullet: again that’s why I wonder why with double isa clock (25MHz) you only get 4000kb instead of my 3500kb with 13 MHz clock. Maybe we run into the pio 0/1 limit instead of isa limit. Or is this bypassed by XTIDE?

With PIO over ISA, the IDE device frequency is hardwired to the ISA bus, they will run at the same clock speed. So if you are running your ISA bus at 13.5 Mhz, your IDE controller will be running at 13.5Mhz, and you are close to making your device PIO-4 w/o IORDY. You should be able to quickly notice if your IDE device cannot handle the faster speeds but I expect almost all IDE device made after 1997 can handle the faster speeds without any problem. [Edit: Cleaned up what I was trying to say]

Here are some things that can cause one drive to appear faster than another on an ISA bus:

• One IDE device supports larger block mode transfers than the other, reducing the number of requests and interrupts needed to transfer the same amount of data. This can have a big impact on linear reads.
• XTIDE is doing P-CHS or LBA or translation for one drive and not the other. Less noticeable with faster CPUs, but there is a measurable impact. https://xtideuniversalbios.org/browser/xtideu … iki?rev=14#L214
• One IDE device is just not as fast as the other. What isn't clear at low speeds can become more clear at the bus speed increases. Maybe the drive can't keep up with a 23MHz bus?

Thanks. I assume we both used hdds / CFs
With muuuuch more capabilties than any PIO mode.

One add-on: according to this page:
https://forum.vcfed.org/index.php?threads/isa … fer-rate.57260/

The cpu speed will make a difference as higher clock speeds will reduce I/O cycle times of the CPU needed for any file transfer (if understood correctly).

I also wonder whether the there mentioned chuck mod can make a difference on our 386 systems as well.

Marco wrote on 2024-04-02, 11:03:

Thanks. I assume we both used hdds / CFs With muuuuch more capabilties than any PIO mode. […]
Show full quote

Thanks. I assume we both used hdds / CFs
With muuuuch more capabilties than any PIO mode.

One add-on: according to this page:
https://forum.vcfed.org/index.php?threads/isa … fer-rate.57260/

The cpu speed will make a difference as higher clock speeds will reduce I/O cycle times of the CPU needed for any file transfer (if understood correctly).

I also wonder whether the there mentioned chuck mod can make a difference on our 386 systems as well.

Most CF's do declare that they support block transfer mode, but their max block transfer size is almost always fixed = 1.

Most HDD's > 1995 support block transfer mode and frequently have a max block transfer size of 16 or larger.

My understanding is that it works some thing like this:

1. CF with block size = 1: Send Read Command for 512 bytes - Wait for CF to process command - Wait for CF to say data is ready - Read 512 bytes from buffer - Repeat 15 more times
2. HDD with block size = 16: Send Read Command for 8 KB- Wait for HDD to process command - Wait for HDD to say first sector is ready - Stream 8 KB from buffer

So the CF has 15x overhead of ATA commands, IRQ's, and Buffer reads, stealing away a lot of ISA cycles. There's probably some latency introduced between each request as well, waiting for the tiny processor in the CF to prep each requests "ala carte" instead of "assembly line". A fast CF's can pull ahead of just about any mechanical HDD in the linear read test, but they need a bus speed that is much higher than the HDD max read speed in order to hide the overhead.

I've seen CPU clock speed have a measurable effect on raw disk transfers with VLB controllers. The higher the CPU clock speed, the faster the transfer rate, with a 133Mhz 486 doing better than a Pentium overdrive. It wasn't large but it was there. I haven't played around with ISA buses faster than 10Mhz, so I'm not sure how much the CPU is going to affect things there.

There are other places where CPU speed can come into play besides raw throughput, such as file system processing, CHS translation, smart drive, etc.

very interesting and might indeed explain my experiances with CF vs HDD as well as the small differences mentioned here between CF@25MHz ISA and HDD@13MHz ISA.

Thanks

AlessandroB wrote on 2024-03-28, 11:14:

Why don't you use a 15k scsi hard disk? i think the result will be different

Short update: tested also this recommendation: results are similar to the ZuluSCSI.

Case „SCSI performance increase“ then closed for me finally 😀

douglar wrote on 2024-04-02, 12:17:

(...) waiting for the tiny processor in the CF to prep each requests (...)

Not trying to nitpick, just pointing out that this "tiny processor" is quite possibly the fastest core on the mobo.
And another obvious statement: Solid storage devices have very low access latency and that alone will make them faster than mechanical drives, however well optimized. For example back in the day I used to run Doom on 4 megs and I would still try to load SMARTDRV (or something like it) even with very small buffer like 128k. This would at least cache FAT structures and speed up HDD access. These days it's better to give Doom more RAM and just run it from CF, it'll result in faster reads and less stutter. My point here being there if you are going to compare ISA-based SCSI solution it better be against PIO 0 mechanical HDD from that era. Already at about 300-400MB of storage space the platter bit density was high enough to saturate IDE, and then ISA itself became bottleneck.

Also let's not forget SCSI was not meant to be a cheap solution, IDE on the other hand was. IDE was plenty fast if all you needed is one disk. Early master/slave setup was anything but trouble-free. With SCSI you could have several drives, even some removable, a streamer and perhaps a scanner as well. It was always a more high-end solution, that didn't see as much adoption so it also didn't evolve as fast as IDE did.

Marco wrote on 2024-04-23, 21:45:

AlessandroB wrote on 2024-03-28, 11:14:

Why don't you use a 15k scsi hard disk? i think the result will be different

Short update: tested also this recommendation: results are similar to the ZuluSCSI.

Case „SCSI performance increase“ then closed for me finally 😀

Did you actually check access times as well as throughput? I've been looking through the topic but didn't see any.

The benefit of SCSI, particularly fast-spinning SCSI was never higher throughput, it was lower access times, due to a combination of being decoupled from whatever the ISA bus is doing, higher rotational speed and less dense platters. The latter actually reduces throughput - a Quantum Bigfoot IDE drive with big slow high-density platters would beat contemporary SCSI in linear transfers, but there's a really good reason people were not happy to run their OS on the Bigfoot but were happy if it was on the SCSI drive. Responsiveness in OS and games correlates inversely with access times, whereas raw throughput is only really interesting in backing up large files.

Testing SCSI on raw throughput is akin to testing an elephant on its ability to climb a tree: not what it's supposed to be good at.

Deunan wrote on 2024-04-24, 13:22:

Not trying to nitpick, just pointing out that this "tiny processor" is quite possibly the fastest core on the mobo.
And another obvious statement: Solid storage devices have very low access latency and that alone will make them faster than mechanical drives, however well optimized. For example back in the day I used to run Doom on 4 megs and I would still try to load SMARTDRV (or something like it) even with very small buffer like 128k. This would at least cache FAT structures and speed up HDD access. These days it's better to give Doom more RAM and just run it from CF, it'll result in faster reads and less stutter. My point here being there if you are going to compare ISA-based SCSI solution it better be against PIO 0 mechanical HDD from that era. Already at about 300-400MB of storage space the platter bit density was high enough to saturate IDE, and then ISA itself became bottleneck.

Also let's not forget SCSI was not meant to be a cheap solution, IDE on the other hand was. IDE was plenty fast if all you needed is one disk. Early master/slave setup was anything but trouble-free. With SCSI you could have several drives, even some removable, a streamer and perhaps a scanner as well. It was always a more high-end solution, that didn't see as much adoption so it also didn't evolve as fast as IDE did.

First, I completely agree that if your app or OS will benefit from more memory, more memory is always going to be a better solution than faster storage.

Second, you are quite correct that more memory can usually hide storage latency issues in real world applications with caching, even if caching solutions are less less capable at increasing scores on synthetic max throughput benchmarks.

The "fastest core" comment raises an interesting question. Early IDE storage devices ran at the IDE bus speed, yes? I think early CF's (1995) may have been the same but it seems like CF's designed after 2000 probably would almost certainly have a separate crystal inside because of the wide range of IDE speeds that came out between 1993 and 1999. Can anyone confirm that?

In this particular case, we were discussing why newer (ATA-4+) mechanical drives were winning the synthetic linear read benchmark on systems with IDE/ISA bus speeds < 20Mhz when compared against much newer CFs that should be quite fast. It looked like the newer mechanical hard drives were winning because they supported block transfer mode with block sizes > 1, which reduced the amount of bus chatter, which is important on systems with a slower IDE bus where the IDE bus is likely the bottleneck. Few CFs support block transfer mode with a block size > 1 so there is significantly more ATA chatter on the linear read test. And I agree that the CF processing time is small, but it still exists, and the calculations to decode CHS into flash banks likely causes a few missed missed cycles here any there, which puts the CF at a further disadvantage, especially if it has to do 16x as many translations as the hard drive. If we were to speed up the IDE bus to something significantly faster than the max transfer rate of the mechanical platters, CF's should be able to overtake the mechanical drive, because the ATA overhead and latency would fall into increasing smaller cracks while the mechanical drives wouldn't go any faster once the max platter speed is reached.

Indeed interesting questions.

Regarding access times: most benchmarks couldn’t measure the random access times correctly on the scsi (showing just 0 or similar). Speedsys is one of the few that seems to be able. scsi 10k around 7,5ms and my latest ide drive reach around 16ms … yes quite a difference indeed here