• Please review our updated Terms and Rules here

Best performing storage option for a 286 Machine

maxtherabbit

Veteran Member
Joined
Apr 23, 2019
Messages
2,153
Location
VA, USA
I'm trying to decide what to go with for primary storage on my 286 - options are CF-IDE or SCSI

SCSI adapter is an AHA-1542B with the old BIOS that only goes up to 1GB, system BIOS only goes up to 504MB on IDE.

Not terribly worried about space concerns on a 286, but I would like to go for maximum performance. CF will obviously be the best with respect to seek time, but I know they are notoriously slow for writes, and not super great for small file reads either.

CF would have the advantage of being a full 16-bit path from drive to processor, whereas SCSI is going to be limited to 8-bit HBA-Drive transfers.

Considering the limitations of a 12MHz 286, which do you guys think would provide best overall disk speed - a CF card or a 5400+RPM SCSI disk with 1MB+ cache?
 
I would use a DOM over the CF. They're much more compatible and easier to configure than the CFs and you don't need an adapter.
 
It's not a simple question.

Unlike IDE/ATA, you can hook several (more than 2) devices to a SCSI channel--and they needn't be mass-storage devices. For example, SCSI-interface scanners should still be fairly plentiful. SCSI has been de rigeur for things like high-end backup tape drives, particularly those with auto-feeders. I'd much rather deal with a SCSI-interfaced Zip drive than with an IDE one.

ATAPI, and for that matter, USB pretty much follow the SCSI standard, but in different physical transport mechanisms.

But if the only thing you'll be using the 1542 for is as a disk interface, I'd go with the IDE (drive, CF or DOM, take your pick). The devices are more plentiful and cheaper.
 
It's not a simple question.

Unlike IDE/ATA, you can hook several (more than 2) devices to a SCSI channel--and they needn't be mass-storage devices. For example, SCSI-interface scanners should still be fairly plentiful. SCSI has been de rigeur for things like high-end backup tape drives, particularly those with auto-feeders. I'd much rather deal with a SCSI-interfaced Zip drive than with an IDE one.

ATAPI, and for that matter, USB pretty much follow the SCSI standard, but in different physical transport mechanisms.

But if the only thing you'll be using the 1542 for is as a disk interface, I'd go with the IDE (drive, CF or DOM, take your pick). The devices are more plentiful and cheaper.

The SCSI adapter is already installed in the machine and will remain there regardless. I really just want to determine which type of disk will be faster on my machine without having to buy a bunch of different things to test personally.

As an aside, as much as I'd love to use a SCSI CDROM in this machine, I don't have one lying around and pricing on them has become oppressive. I'm using a Sony 52x ATAPI CD connected to the IDE controller right now to good effect.
 
On a 286, it may not matter, but on faster (e.g. P1 systems), I've found that CF performance leaves a lot to be desired, period. Perhaps DOM is better, but spinning rust is still best.

As regards capacity, the IDE/ATA basics haven't changed much since their adaptation from ESDI. Support capacity is mostly a matter of BIOS or system software, not hardware. On SCSI, the 1GB limitation is mostly from the software/BIOS using 6-byte CDBs for access, but there's no practical reason that software couldn't be upgraded to use 10 or 13 byte CDBs.

If you're looking for performance and everything else is equal, I'd use spinning rust and forget about the solid-state stuff unless you have some compelling reason not to do so. Use whatever interface you prefer--on a 286 system, you won't be able to tell the difference.
 
I'm puzzled by the desire for "maximum performance" on a 286. It's very much like saying "I want the fastest slow machine I can get".

I think the fastest option is probably to use an Adaptec AHA-1542CF, combined with a SCSI2SD SD card adapter. This will give you all the benefit of busmaster DMA transfers, and the speed of flash memory.

If you are constrained to only choosing between CF-IDE or a SCSI spinning platter drive, I would probably go with the CF-IDE because eliminating seeks is likely to be the most significant performance benefit. If you have (or can get) a busmaster IDE adapter that would help too, because PIO transfers consume CPU cycles that then can't be used for other tasks. If you can't, the benefits of busmaster DMA transfers may outweigh the elimination of seek time delays (especially with a fast SCSI drive) so a SCSI spinning drive is still a good option.

If it were me, I'd stick with a spinning platter drive simply because it's more "period-correct" and the sound of heads seeking is an important part of the retro experience. Speed is something I demand from my newest systems, not my oldest ones.
 
On a 286, it may not matter, but on faster (e.g. P1 systems), I've found that CF performance leaves a lot to be desired, period. Perhaps DOM is better, but spinning rust is still best.

As regards capacity, the IDE/ATA basics haven't changed much since their adaptation from ESDI. Support capacity is mostly a matter of BIOS or system software, not hardware. On SCSI, the 1GB limitation is mostly from the software/BIOS using 6-byte CDBs for access, but there's no practical reason that software couldn't be upgraded to use 10 or 13 byte CDBs.

If you're looking for performance and everything else is equal, I'd use spinning rust and forget about the solid-state stuff unless you have some compelling reason not to do so. Use whatever interface you prefer--on a 286 system, you won't be able to tell the difference.

Thanks - that's exactly the kind of feedback I'm looking for. Maybe I'll just grab a decent performing SCSI drive to use as my boot volume and use the CF-IDE adapter as a secondary disk for convenience sake i.e. being able to pop the card out of the back of the case without opening it for large transfers.

Maybe I need to suck it up and buy an EPROM burner already so I can upgrade the SCSI BIOS and burn an XT-IDE ROM to transcend the motherboard limitation.
 
"I want the fastest slow machine I can get"

that's pretty accurate lol

I'm not aware of any busmaster ISA IDE controllers existing, but perhaps I'm wrong about that.

There will be at least one platter drive attached to this system regardless. Just a question of what single item to splurge on - meaning purchase. Every thing else was scrounged.
 
If you're concerned about spinning disks and seek time (CDC used to call these "RMS" for "Rotating Mass Storage", a good descriptive name), you may want to locate an ISA caching IDE controller. Promise made some pretty good ones, as did GSI--there may be others; I haven't investigated the matter extensively. I think you may get better performance on an ISA bus with one of these than with a busmastering IDE controller (pretty rare, AFAIK). Stick a few MB of cache memory on a controller and you don't need to worry about seek latency for most things.
 
If you're concerned about spinning disks and seek time (CDC used to call these "RMS" for "Rotating Mass Storage", a good descriptive name), you may want to locate an ISA caching IDE controller. Promise made some pretty good ones, as did GSI--there may be others; I haven't investigated the matter extensively. I think you may get better performance on an ISA bus with one of these than with a busmastering IDE controller (pretty rare, AFAIK). Stick a few MB of cache memory on a controller and you don't need to worry about seek latency for most things.

I'm thinking a 7200RPM SCSI drive with 1MB on-drive cache might be the way to go, no?
 
Any decent "modern" SCSI drive will saturate the ISA BUS on a 286. There are plenty of smallish quick 68 pin or SCA drives you can convert to 50 pin that are faster then any IDE or MFM drives that would have shipped with a fast 286 back in the day.

IDE wasn't that good until they came out with EIDE with DMA transfers. For low CPU overhead I go with SCSI on 286, 386, and early 486 ISA only systems. Once you get into VLB a caching EIDE controller makes more sense but there are speedy VLB SCSI cards (even with cache).
 
The hands-down fastest will be the CF card, for the simple matter that it outperforms any spinning rust drive in number of I/Os (seeks) per second, by orders of magnitude. There are very few situations on a 286 DOS machine where you need to read more than 64K contiguously/continuously, but just about every situation requires a lot of seeks.

You could always implement them both and do some benchmarking. https://www.lo-tech.co.uk/wiki/DOS_Disk_Tester works well.
 
The hands-down fastest will be the CF card, for the simple matter that it outperforms any spinning rust drive in number of I/Os (seeks) per second, by orders of magnitude. There are very few situations on a 286 DOS machine where you need to read more than 64K contiguously/continuously, but just about every situation requires a lot of seeks.

You could always implement them both and do some benchmarking. https://www.lo-tech.co.uk/wiki/DOS_Disk_Tester works well.

Good info at that link, I can use that utility to determine the effectiveness of smartdrv and also the I/O performance effect of using DOSDATA=UMB (since my UMBs reside in hercules video ram) as well, thanks!
 
(since my UMBs reside in hercules video ram) as well, thanks!

That is a bad idea. Most video RAM of that era has additional wait states, and even faster VGA cards have much slower read times than write times.

Yes, in my time in the demoscene we used to pull all sorts of silly crap, like putting audio samples in video RAM and graphics data in soundcard RAM, but that was for LOLz. Don't do it for real :)
 
That is a bad idea. Most video RAM of that era has additional wait states, and even faster VGA cards have much slower read times than write times.

Yes, in my time in the demoscene we used to pull all sorts of silly crap, like putting audio samples in video RAM and graphics data in soundcard RAM, but that was for LOLz. Don't do it for real :)

Yes I'm aware. I tried using DOSDATA=UMB and immediately noticed a degradation in my DOS file I/O performance. I would like a good utility to quantify said degradation though.

I don't plan to use DOSDATA=UMB on an ongoing basis, I'm still able to get well over 600kb free without it. But as far as using the herc RAM as UMB, I really have no other choice on a 286 with no chipset support for shadow RAM. (Except for purchasing a 1MB lo-tech RAM card I guess)

I don't think loading DOSKEY, COMMAND.COM and my CDROM drivers into VRAM is really going to slow anything down in a meaningful way. CDROM I/O speed is not a big concern to me.
 
If you're able to get over 600K without using UMBs, then you're essentially done. There isn't any single piece of software that requires more than 580KB free DOS RAM.

You'd get more benefit at this point from installing hardware EMS (but only if you have an application or environment that can use EMS).
 
If you're able to get over 600K without using UMBs, then you're essentially done. There isn't any single piece of software that requires more than 580KB free DOS RAM.

You'd get more benefit at this point from installing hardware EMS (but only if you have an application or environment that can use EMS).

I still have to use UMBs for the TSRs I listed to get over 600k. But I do not have to use the PC-DOS feature of loading the STACKS, FLIES and BUFFERS into UMB - which is what produced the noticeable slowdown.
 
The hands-down fastest will be the CF card, for the simple matter that it outperforms any spinning rust drive in number of I/Os (seeks) per second, by orders of magnitude. There are very few situations on a 286 DOS machine where you need to read more than 64K contiguously/continuously, but just about every situation requires a lot of seeks.

On faster machines with PCI-oriented IDE controllers, I've never found that any CF on an adapter card outperforms a good Ultra ATA drive. I base my opinion with an A-B comparison on how fast Win2K boots up on either--same system, only the disk changed--the 80-conductor cable remains the same.

The difference is palpable.
 
...There isn't any single piece of software that requires more than 580KB free DOS RAM...

I can think of at least one game that needs more than 600K. Falcon 3.0 claims to need 602K ;) From the manual;
"Due to the realism and complexities of the game, Falcon 3.0 requires a lot of free conventional memory to operate: 602K or 616,448 bytes"

Greg

Edit, OOPS! I just realized the OP is using a 286. I believe Falcon 3 needs at least a 386. So maybe that's a bad example.
 
Back
Top