More Data on CF to IDE to SCSI

To get a better picture of the performance of the CF to IDE to SCSI solution, I moved the Adaptec 1542C into one of my favorite boards, the Alaris Cougar with a classic Intel 486 DX2 OverDrive CPU.

For a 486, the board has a surprisingly fast IDE controller, an Adaptec 25-VL010 (that’s a VLB IDE controller). With a CF card plugged to the onboard IDE connector, Norton SysInfo 8.0 shows whopping 7 MB/s transfer speed. That is in fact much better than what a typical PCI Pentium board can do (around 3-4 MB/s is common).

AHA-1542C (ISA) and AHA-2842A (VLB)

The performance of the 1542C was somewhat disappointing. That is to say, it was no faster than the ISA-only 386 board, and if anything just a tad slower, with slightly under 2.5 MB/s transfer rate. I tried increasing the AHA-1542C DMA transfer rate from the default 5 MB/s but couldn’t push it much and it made little difference.

What did make some difference was shadowing the Adaptec BIOS. I found a fascinating AST Research Technical Bulletin #0744A which explains that Adaptec 154x may be slower in 486 systems than in 386 systems because the 16-byte cache line code fetches from the ROM take too many bus cycles. That would explain why shadowing helps.

The bulletin might actually be slightly inaccurate because at least the 1542C has in fact shadow RAM for the BIOS code. The ROM is copied into RAM on the adapter, modified here and there, and then used. As a result, the shadow RAM must be read-write and not read-only, otherwise the 1542C BIOS cannot initialize! However, even though the Adaptec HBA may do its own shadowing, what makes a difference is whether the BIOS code needs to be fetched over the ISA bus or not.

OK, so with the 1542C we’re stuck at around 2.5 MB/s. Is that a problem with ISA, with the 1542C, or with the Acard IDE-to-SCSI adapter? It’s not the CF card, I know that much. But the 486 performance does show that the transfer speed on the 386 system really was not limited by the CPU.

VLB SCSI

The next step is an Adaptec AHA-2842A, which is a VL-Bus SCSI HBA. And yes, it does make a difference. SysInfo now reports almost 6.1 MB/s transfer speed! Which is actually still not as good as the onboard Adaptec IDE controller, but more than respectable for a 486.

At this point I realize that the AHA-2842A is a Fast SCSI adapter, and the AHA-1542C is not. What that means is that the 1542C is limited to a maximum 5 MB/s transfer rate on the SCSI bus side, while the 2842A goes up to 10 MB/s. It is also obvious that the Acard adapter does support Fast SCSI (not too surprisingly) because it gets past 5 MB/s.

So, can we do better on ISA? Let’s see…

Fast SCSI on ISA

All I need to do is find an ISA-based Fast SCSI HBA. Fortunately there’s an Adaptec AHA-1540CF in my junk pile. And with that, we get to 2.7 MB/s in SysInfo, which is better than the 1542C, but really not much better. During this exercise, I also learn that it really does matter how the SCSI cable is routed (corrupted transfers are no fun).

At this point I discover that by default, the 1540CF does not do Fast SCSI and it needs to be enabled manually. After doing that… the transfer rate is entirely unchanged at 2.7 MB/s.

So what happens if the AHA-1542CF DMA transfer rate is increased to 6.7 MB/s from the default 5 MB/s? That makes a difference and SysInfo now reports close to 3.4 MB/s. This suggests that the ISA bus is really the bottleneck, not SCSI.

And that theory is confirmed by disabling Fast SCSI again. SysInfo still reports almost 3.4 MB/s. Unfortunately it’s not possible to use the next higher DMA speed (8 MB/s), the system simply isn’t stable and won’t boot at all.

There’s one more thing to try, enabling the R/W shadow for the 1540CF BIOS. And yes, that still helps! SysInfo now reports almost 3.7 MB/s, better than before. Again the Fast SCSI setting has no noticeable effect. But really, 3.7 MB/s disk transfer speed on ISA is not at all bad!

And Back to VLB for a Moment

So wait… what if the R/W BIOS shadow is enabled for the VLB adapter? Does the AHA-2842A care? Why yes! The disk transfer speed shown by SysInfo goes from 6.1 MB/s all the way up to 8.4 MB/s, that’s more than one third faster. Now the SCSI transfer speed finally beats IDE on this board (8.4 MB/s on SCSI vs. around 7 MB/s on IDE).

As expected, changing the SCSI transfer rate now has visible impact on the overall speed. At 5.0 MB/s SCSI transfer rate, the SysInfo-measured disk read speed is 3.8 MB/s and 4.6 MB/s, without and with BIOS shadowing, respectively.

To recap, when the HBA allows the maximum 10.0 MB/s SCSI transfer rate, the SysInfo-measured disk transfer rate is 6.1 MB/s and 8.4 MB/s (without and with BIOS ROM shadowing). When the performance isn’t hampered by BIOS ROM accesses over the ISA (or VL) bus, the measured disk speed is not too far from the theoretical maximum SCSI bus transfer speed and far exceeds the ISA transfer speeds. There’s a reason why VLB was popular, even with all its quirks.

What About EMM386?

The above numbers have all been obtained in a true real-mode environment with HIMEM.SYS loaded but no EMM386 or similar memory manager which would enable V86 mode, paging, require VDS (Virtual DMA Services), and presumably slow things down.

And indeed, enabling EMM386 on the Cougar board with a 66 MHz 486 DX2 slowed the transfers from 6.1 MB/s down to 5.7 MB/s (no ROM shadowing in BIOS). That is not a dramatic slowdown but it is a slowdown. Without in-depth analysis, it should be safe to assume that at least VDS and V86 mode contributed.

But wait, it’s not all bad. EMM386 also offers the option to shadow ROMs (ROM=D800-DFFF in CONFIG.SYS on the tested system). And just like letting the BIOS do it (probably not every BIOS can!), EMM386’s shadowing makes a big difference. The transfer rate goes from 5.7 MB/s to slightly over 8.3 MB/s. That is almost as good as using BIOS shadowing and no EMM386 (that went up to 8.4 MB/s). In other words, EMM386 can make a difference, both negative and positive.

Revisiting the 1542C

Given that Fast SCSI doesn’t seem to do much for the 1540CF, is there more to be done for the older 1542C? Of course there is.

Bumping up the ISA transfer rate to 6.7 MB/s again does little and the transfer rate is stuck at 2.4 MB/s. That’s with no ROM shadow; the ROM shadowing has the unfortunate side effect that the Adaptec configuration utility can’t be called up.

Remember, the 1540CF achieved nearly 3.4 MB/s in this configuration. It turns out that the magic setting on the 1542C is “enable sync negotiation” (off by default). Lo and behold, with sync negotiation on, the 1542C gets to the same 3.4 MB/s and 3.7 MB/s (without/with ROM shadow) transfer speeds.

And to the 386 Again

Which means I need to re-test the 386 to see if it does benefit from the sync negotiation. Not too surprisingly, it does. The 386 can now read at just under 3.3 MB/s from the CF card over SCSI.

When shadowing is enabled for the Adaptec BIOS on the 386 board, things improve once more. Again, the reason for the speed-up is that with shadowed BIOS, the SCSI transfers do not need to contend with BIOS code fetches over the ISA bus. The transfer rate in the 386 board with the 1542C is 3.7 MB/s. That’s impressive for an ISA-only 386 where IDE gets slightly past 1 MB/s on a good day.

At this point, I declare victory and go home.

This entry was posted in 486, CompactFlash, IDE, Storage. Bookmark the permalink.

16 Responses to More Data on CF to IDE to SCSI

  1. rasz_pl says:

    3.3 MB/s over ISA is pretty good considering fastest VGA cards are around 5MB/s, and reading ram on 386DX40 is somewhere at 14MB/s.

    Were there ever ISA IDE controllers with bus dma?

  2. Michal Necasek says:

    Yes, I was a bit surprised to get actual 3+ MB/s transfer speeds. I think the theoretical max with ISA is about 8 MB/s, but that would require 0WS up and down the chain which probably isn’t realistic. Testing other ISA SCSI HBAs would be interesting too, the AHA-1542C is not necessarily the fastest thing out there.

    The difference between VLB and ISA is also pretty big, VLB is more than 2x faster just like that. And in the VLB case I am pretty sure the system is hitting the 10 MB/s SCSI transfer rate limit, not the VLB bandwidth limit (while on ISA the system bus is definitely the bottleneck).

    I don’t know of any ISA IDE controllers with DMA but that doesn’t mean there weren’t any. It certainly would have been very, very uncommon. IDE DMA more or less post-dates ISA, but I can imagine some caching disk controller using DMA. Then again that would not be quite IDE because it’d need its own BIOS and drivers.

  3. raijinzarel says:

    As far as i know, only CMD made what you could call ” ISA IDE controllers with DMA”, and their implementation was bugged as hell, in the extreme you had to disable the DMA engine to make the thing stable. All the rest of ISA IDE controllers with DMA out there (and also VLB/EISA and the first PCI ones), particularly the ones with caching-on-ram feature, weren’t proper IDE controllers (in the sense you can’t access them with the standard IDE OS/BIOS framework) but full fledged SCSI-like HBA controllers, and generally the OS will access them through the bundled SCSI framework (CAM/SPTI/ASPI) with the help of a sort of miniport driver for each controller installed in the system. Promise and Tekram made many of these style of IDE controllers.

  4. Chris M. says:

    The VLBus IDE controllers were all PIO Mode 4 at best (hello CPU overhead), no DMA that I know of.

    Best info on VLBus IDE is here: http://www.ryston.cz/petr/vlb/vlbidechips.html

    You had to go PCI for DMA, but all those early on-board CMD-640 controllers couldn’t be trusted to do it correctly. Reliable IDE DMA for the masses didn’t arrive until Triton’s PIIX southbridge showed up, and even then you had to wait until 1996 to use it since DMA support was only added in 95 OSR2.

    Now I’m curious how the EISA Adaptec AHA-2740W performs using wide SCSI devices. It has the same family controller (AIC-77xx series) as the AHA-284xVL, but Adaptec didn’t seem to want to give the VLBus folks wide SCSI.

  5. Richard Cranium says:

    A bit OT but…

    WOW! Coaxing 7MB/sec out of a IDE drive on a 486. That’s just awesome.

    I was really chuffed with myself getting over 5MB/sec out of mine – as I was well aware of the barely-4MB/sec PCI adapters were capable of at the time.

    VLB IDE and a nice Tseng Labs ET4000/W32p, not fighting with each other – while the VLB was running at 50MHz(!) – caused me to hold onto that 486 (well, 5×86) a whole lot longer than I should have. πŸ™‚

  6. Michal Necasek says:

    I have one of those Tekram PCI thingies somewhere (circa 1994). With 8-16 MB cache RAM, it gets interesting πŸ™‚

  7. Michal Necasek says:

    In DOS/BIOS, no one could care less about CPU overhead πŸ™‚ One interesting feature the Adaptec VLB IDE chip has is 32-bit PIO support on the CPU side. That adds more than 1 MB/s IIRC (and reduces CPU overhead).

    I remember the CMD-640, it was the IDE controller from hell. All sorts of bugs.

    EISA could be worth testing, I have some reasonably speedy Pentium PCI/EISA boards (all Intel chipsets) where the CPU certainly shouldn’t be a bottleneck. I don’t have a 2740W but I have some older Adaptec and BusLogic EISA HBAs.

  8. Michal Necasek says:

    The problem with VLB was never speed πŸ™‚ I was quite surprised that this particular board (1994 vintage) does 7+ MB/s on IDE, especially because I’m all too familiar with all the newer PCI boards which do half of that. And now I really wonder why the PCI boards are so much slower.

  9. Yuhong Bao says:

    Ah, CMD-640 and RZ-1000. Let’s just say that if OS/2 2.x actually replaced DOS/Windows, the controller would not likely have been shipped with the bugs it had.

  10. Richard Cranium says:

    > And now I really wonder why the PCI boards are so much slower.

    I was about to shout “33MHz bus speed”, but then realised that most people’s VLB would have been running at 33MHz (or even 25MHz, for the 50MHz clock-doubled crowd) too…

    Likely all the extra trimmings your flash Adaptec card has. I spy with my little eye some DIP switches up the top of the board there: flicking a few along there would no doubt kill performance.

    The funny thing is though, I recall my VLB IDE controller being an el-cheapo. Picked it up for a tenner at some side-street computer shop. Was only half the height of yours, included super I/O (the usual two serial, one parallel, one game port of the era), and only one IDE channel.

    Erm… this ranty dance was way smaller while it only existed in my head. End of OT. πŸ™‚

  11. Michal Necasek says:

    The Adaptec VLB card in the photo is a SCSI HBA. The IDE VLB chip in question is also Adaptec, but soldered on my board. It has no jumpers actually, but it does have a couple of config options in the BIOS.

    What may play some role is that the board has MR BIOS (Microid Research), not the usual AMI/AWARD, and MR BIOS is… different. That is just speculation though.

  12. zeurkous says:

    Thanks, this is quite useful. Could you do me a certain favour and test the speed of the bridge config w/ a modern system? I wonder how (and if!) well it works without the host machine being the bottleneck…

  13. zeurkous says:

    @PCI: I, of course, wouldn’t know the exact details, but a little voice in the back of my mind yells “bloat” everytime I read “PCI”…
    Pure coincidence, I’m sure.

  14. Yuhong Bao says:

    BTW, I just found out that zero wait state on ISA only works for 16-bit memory accesses.

  15. Michal Necasek says:

    Yes, that is pretty well documented in Mindshare’s ISA System Architecture, for example. 16-bit I/O and 8-bit anything requires at least 1WS.

    I should probably dust off that 8 MB ISA memory board I have and see how fast that is.

  16. Disruptor says:

    Well, that EISA 2740W / 2742W is whopping about 18 MB/s. No joke!
    I have tested the 2842VL too and it seems that Adaptec has put a lot of logic chips on that card to adapt the same SCSI chip on the EISA controller to work on the VLB.
    I was not amused by the performance, but I’ll have to test it with shadow or loaded ASPI driver again.

    Remember, mkarcher has written a patch to the 274x(W) BIOS and 284x(VL & A) BIOS to support SCSI disks sized above 8 GB. You find it in karcherm repository on GitHub.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.