To see how the CF-to-IDE-to-SCSI solution really performs, I tried it in a slightly faster system. GA-586HX motherboard (Intel 430HX chipset), AMD K5-133 processor, and PCI SCSI HBAs.
The first tested configuration was using a Tekram DC-390 HBA. Sysinfo showed 8.7 MB/s, not much more than the 8.4 MB/s the VLB 486 reached. The limit here is probably the 10 MB/s Fast SCSI transfer rate and we’re getting close to 90% of the theoretical maximum, although a different HBA would perhaps do better. The DC-390 is a Fast SCSI HBA limited to 8-bit wide transfers and 10 MB/s.
The second HBA was a classic Adaptec AHA-2940UW, but it did slightly worse than the Tekram, at a little under 8.6 MB/s. But wait, the ‘U’ in 2940UW stands for Ultra, and the Acard IDE-to-SCSI adapter is the 7720U, where ‘U’ once again indicates Ultra SCSI. So why can’t we get past 10 MB/s?
Because the 2940UW does not enable Ultra SCSI by default. And sure enough, enabling it bumped up the speed a little: 10.6 MB/s. That’s not a lot better but clearly we’re past 10 MB/s. At this point it’s unclear what the bottleneck is. It could be the PCI bus, host board, CPU, DOS, the HBA’s BIOS, the CF card, or perhaps something else. The system should have sufficient memory bandwidth (about 60 MB/s write throughput) and BIOS ROM access should not be an issue on a PCI board (it’s all copied into RAM anyway).
The system feels snappier than when the same CF card (a 1.0 GB SanDisk Ultra II) is attached to IDE directly. Sadly I find myself unable to compare the speed with Sysinfo due to geometry problems (an odd issue that I won’t go into now), namely Sysinfo refusing to benchmark the disk when it’s attached to IDE.
So let’s try a different card, a 2.0 GB SanDisk Ultra III. It does rather well with IDE, showing 9.2 MB/s on this motherboard. But whoops… Sysinfo fails again, this time not because it can’t see the disk but because it shows 0.0 MB/s when it’s attached via SCSI!
So let’s try Speedsys 4.78. For the SanDisk Ultra III CF card attached via IDE, it shows 8,579 KB/s buffered read speed and 8,372 KB/s linear read speed. When attached via SCSI, the values jump up to 13,310 KB/s buffered read speed and 11,752 KB/s linear read speed. It’s ironic that CF-to-IDE-to-SCSI is faster than a direct CF-to-IDE connection.
With PC-CONFIG V8.20, the figures are as follows. When using direct CF-to-IDE connection, PC-CONFIG reports 11,532 KB/s linear read speed and max throughput of 8,851 KB/s. Going CF-to-IDE-to-SCSI, we get linear read speed 23,064 KB/s, max throughput 13,519 MB/s. The throughput is presumably the more important figure. 13.5 MB/s is not at all bad for a Pentium system; and again it’s noticeably better than the same CF card via IDE.
In this configuration, it makes a big difference what kind of CF card (or Microdrive) is plugged into the IDE-to-SCSI adapter. Many CF cards can’t achieve such speeds and top out at 5 MB/s or less.
The conclusion is that the CF-to-IDE-to-SCSI solution performs quite well, and a relatively fast CF card is required to get past 10 MB/s. For vintage systems the performance is more than adequate.
Apologies for the lack of photos in this post.
I see that my wish has been (partially) granted, thank you! Did you figure out a solid mechanical arrangement?
Shouldn’t a k5 have much higher memory throughput than 60 mb/sec? Pentium class is usually 64-bit * 66 mhz or 533mb/sec theoretical max?
Would a promise ultra ATA/33 adapter in a PCI slot not be even faster?
Not really, but that wasn’t my objective 🙂
The Promise card should perform well in DOS. The PCI option ROM enables UDMA mode for supported drives, unlike the on-board IDE controllers (likely a fail safe move by the BIOS). Usually to get DMA transfer in DOS with motherboard controllers, you have to load a UDMA driver like FreeDOS includes. This might not make much of a difference with a pre-UDMA chipset like the 430HX-PIIX3 though.
Promise controller — not sure, don’t have one. Maybe it would be faster, maybe not.
The theoretical max is what the front side bus might be capable of. FPM or EDO DRAM gets nowhere close to that, 533 MB/s bandwidth would be in the DDR SDRAM range.
http://www.pcguide.com/ref/cpu/fam/g5K5-c.html
K5-133 – 508.6mb/sec.
You’re right fpm and edo are slower but they do appear capable of 200-266mb/sec at least. http://www.bunniestudios.com/bunnie/dramfaq/SDRAMpic.GIF
BTW I love these articles on the old machines. Are we going to see Arcos 5 (the update to os/2) in the future ? Looks like it releases soon.
Those are highly theoretical numbers. Both the max data bus bandwidth figures and the DRAM figures. That said, my notes indicate that memtest86 4.20 reported 104 MB/s main memory bandwidth for the GA586HX + K5 PR133. A lot depends on exactly how the bandwidth is calculated. But 400 MB/s for EDO is a joke, actual machines are lucky to get near 150 MB/s. 400 MB/s is what a good chipset might get with fast SDRAM.
Still well in excess of the 10mb/sec you are getting for the CF card 🙂 I was just trying to state I doubt the bus or ram speed are the limits there – it’s probably the controller or CPU speed.
Certainly. Since the SCSI transfers use bus-mastering, it’s not the CPU. For the Fast SCSI HBAs, the limit is definitely the SCSI bus (10 MB/s), no question about that. For the Ultra SCSI HBA (20 MB/s theoretical max), the limit is either the HBA, the IDE to SCSI converter, or the CF card itself. The PCI bus and RAM should have significantly more bandwidth than that.
If you want, I’m pretty sure I’ve got one or two Promise PCI IDE controllers, and I could send you one.
https://forum.vcfed.org/index.php?threads/640×400-256-color-mode-on-standard-vga.1227391/post-1227523
“By modern standards expecting sustained 25Mbyte or 28Mbyte/s performance from a 32 bit wide memory array doesn’t sound like too much to ask, but in 1987 that was actually a little bit ambitious for consumer-grade hardware. (By IBM’s standards, anyway. Something to remember is that IBM was never ambitious when it came to the PC line, the hardware engineering was always conservative for the time.) ”
At the time the most common DRAM was something like 256Kbit DRAM at something like 120ns, right?
I suspected that the memory in a standard VGA might not be able to push the pixels fast enough. So yes, the memory bandwidth was a problem.
I don’t know what IBM put in their VGAs but it could have been 120ns, or it could have been even slower.