Maybe your big 80GB ATA drive wasnt optimized for such a controller.. It also can happen, that the through put on the 80GB was to much for the VLB connection, so the overhead became much bigger.

Also your VLB accelerator card could have a to slow 80186 or 80286 processor to drive the board, which will be the bottleneck on you 80GB drive.

I think that a 1 - 8 GB harddisk would perform much better. And that also would be the limit.

It could also be that the Samsung drive's built-in cache is fast enough to somewhat negate the benefits of the caching controller, and thus the overhead makes things worse.

Do you have any smaller drives besides the Connor? Like someone has already said the 80GB drive is just too modern and likely had some issue with the controller.

Pretty cool that you manage to get this card seeing how quick people are ready to throw down their bottom dollar for good gear these days.

That Promise controller isn't EIDE. Maybe that's slowing things down. I would assume the bottleneck is from the drive to the cache and not from the cache to RAM.

Can you test it with an "real life" example? Not sure what would be OK for an 486, maybe booting Windows 95?

Robin4 wrote:

Also your VLB accelerator card could have a to slow 80186 or 80286 processor to drive the board, which will be the bottleneck on you 80GB drive.

It has a Harris 286 20mhz. Still I think something is off, especially on the ISA vs VLB cards I tested. VLB should increase the bus transfer capacity and in theory give better performance, but there could be a bottleneck somewere else.

alexanrs wrote:

It could also be that the Samsung drive's built-in cache is fast enough to somewhat negate the benefits of the caching controller, and thus the overhead makes things worse.

Yes, it has 2MB of cache and that is about the recommended amount of RAM cache for a 486 system according to PC Magazine.

Do you have any smaller drives besides the Connor? Like someone has already said the 80GB drive is just too modern and likely had some issue with the controller.

Pretty cool that you manage to get this card seeing how quick people are ready to throw down their bottom dollar for good gear these days.

I have a 2.1 GB Bigfoot I could test, but beside that I dont own so many older IDE drives.

That Promise controller isn't EIDE. Maybe that's slowing things down. I would assume the bottleneck is from the drive to the cache and not from the cache to RAM.

It doesn't support the official EIDE, but it does the same things. According to the documentation, maximum speed is 19 Mbyte/sec (this is probably cache transfers).

Can you test it with an "real life" example? Not sure what would be OK for an 486, maybe booting Windows 95?

Was thinking of expanding to more benchmarks for disk, Winstone is very real life. Could also do Speedsys. Phil, what do you use?

Is you card the DC4030-VL? or the DC4030-VL2 like is shown on the box. I have seen several variations of this card the DC4030-VL model I have has a i286 coprocessor on it and have seen others with Siemens, Midland, and Harris labeled coprocessors. There is actually a number you can call and order the updated Bios for this card I have been meaning to order one for myself before that service gets shut down

stuvize wrote:

Is you card the DC4030-VL? or the DC4030-VL2 like is shown on the box. I have seen several variations of this card the DC4030-VL model I have has a i286 coprocessor on it and have seen others with Siemens, Midland, and Harris labeled coprocessors. There is actually a number you can call and order the updated Bios for this card I have been meaning to order one for myself before that service gets shut down

It's the DC4030VL-2 as shown on the box. I have my doubts that BIOS service is still operational as it was removed from Promise's website in 2001. Haven't tried to mail/contact them though. I just need the files, as burning them on EPROM is not the biggest problem.

In theory fast disk would provide cache card useless as the bottleneck is the VLB or ISA bus itself - like CF cards now-a-days.

I have one VLB cache controller but haven't yet tested it.

Benefit of the cache controller is mainly in its own logic. You don't have to use Smartdrive and extra PC memory storing the cached data. Smartdrive also uses some CPU time for doing it's job. Said that, you'd have to disable all software disk caches - Smartdrv and also in Windows as it's getting overlapped.

I would do a simple test. Max out the cache on the board (16MB) and run Windows 3.11 or 95. Stopwatch the loading time, exit Windows and run again. This should be done on a old HDD as there would be the most benefit of a fast cache. Do the same test with CF card and probably there wouldn't be much benefit at all.

As for the other tests. I'd use Checkit and Comptest. Also if there exist something that is CPU and HDD intensive at the same time - like BatteryEater for testing laptop battery for newer systems.

kixs wrote:

In theory fast disk would provide cache card useless as the bottleneck is the VLB or ISA bus itself - like CF cards now-a-days. […]
Show full quote

In theory fast disk would provide cache card useless as the bottleneck is the VLB or ISA bus itself - like CF cards now-a-days.

I have one VLB cache controller but haven't yet tested it.

Benefit of the cache controller is mainly in its own logic. You don't have to use Smartdrive and extra PC memory storing the cached data. Smartdrive also uses some CPU time for doing it's job. Said that, you'd have to disable all software disk caches - Smartdrv and also in Windows as it's getting overlapped.

I would do a simple test. Max out the cache on the board (16MB) and run Windows 3.11 or 95. Stopwatch the loading time, exit Windows and run again. This should be done on a old HDD as there would be the most benefit of a fast cache. Do the same test with CF card and probably there wouldn't be much benefit at all.

Also if there exist something that is CPU and HDD intensive at the same time - like BatteryEater for testing laptop battery for newer systems.

Intensive CPU and HDD is Winstone for you. I dont really understand why people don't use these benchmarks more. It's real life applications like Coral Draw, Lotus 1-2-3, Filemaker, etc being macro'ed.

Good point on the other cache stuff. I'll see if there is any difference turning off 32 bit file access and Smartdrive.

I found my Adaptec AVA-2825VL controller which is SCSI, Floppy and EIDE all into one VLB card. The benchmark with the Samsung drive really improved while the Connor stayed at about the same! Getting a VLB EIDE controller is something to consider if you have a more modern drive.

I must have done something wrong with the no-name VLB IDE controller I have on the previous test. I researched it and it seems one of the factory default jumpers was not set correctly (http://stason.org/TULARC/pc/hard-disk-floppy- … L-SUPER-I-O.htm).

Plan for further testing:

1. Add Bigfoot 2.1GB and WD 6.4GB IDE drives into the benches.
2. Expand with more benches. Winstone, Speedsys and ATTO/HD Tach (I'll install Win95).
3. Test the DC4030VL-2 cache controller again with Smartdrive and 32 bit file access deactivated. Then with hardware cache deactivated.

4. Compare results with the BusLogic BT-410A VLB IDE cache controller when I receive it in the mail.
5. Add SCSI into the mix (when I get 68pin to 50 pin adapter so I can add 15k RPM disks). I don't have a SCSI cache controller, only ISA and VLB, so can't test if cache makes any difference there.

6. I also have an EIDE ISA card (Promise EIDEMAX II) on the way, this will also be benched.

Interesting.

Can you run these tests with a CF card? I have often wondered if the speed of the flash memory somewhat (if not completely) negates the advantage the cache would offer.

HighTreason wrote:

Interesting.

Can you run these tests with a CF card? I have often wondered if the speed of the flash memory somewhat (if not completely) negates the advantage the cache would offer.

I'll see what I can do. I think I have a CF card laying around somewhere, although I thought IDE to SD card was the new thing now as it has better performance?

Never used an IDE-to-SD as it is prohibitively expensive. I have no idea how well they perform but I don't have much confidence due to them converting between two interfaces, I could be wrong.

I haven't had any issues with CF card performance personally, using primarily Kingston cards, to a point where testing with my 40MHz 486 alleges a speed close to the limit for the adapter's IDE interface and a brief spike close to the absolute limits of the BUS (Around 160MB/s) but have never tried to confirm the accuracy of these tests, only going on the simple fact that the cards/adapters were cheap and they seem fast enough for what I am trying to do with them. This example uses a Promise branded controller, no cache but it does have its own BIOS.

HighTreason wrote:

Never used an IDE-to-SD as it is prohibitively expensive. I have no idea how well they perform but I don't have much confidence due to them converting between two interfaces, I could be wrong.

I haven't had any issues with CF card performance personally, using primarily Kingston cards, to a point where testing with my 40MHz 486 alleges a speed close to the limit for the adapter's IDE interface and a brief spike close to the absolute limits of the BUS (Around 160MB/s) but have never tried to confirm the accuracy of these tests, only going on the simple fact that the cards/adapters were cheap and they seem fast enough for what I am trying to do with them. This example uses a Promise branded controller, no cache but it does have its own BIOS.

Phil have good results from them and prices have gone down, see his video:
https://www.youtube.com/watch?v=Yn9vwOf19XE

My experience with CF cards is that work fine in DOS, but in Windows they are painfully slow due to the slow performance on small files. I recon games loading many small files will have similar issues.

I'd avoid using SD cards altogether on a retro-machine until someone analyses if these controllers have any sort of wear leveling. With CF cards you can pretty much trust a good quality card itself will do it, and that the adapter can only do so much to screw up (since all the logic is in the card itself). With SD cards the controller plays a much bigger role, so there could be some good chips and some crappy ones, just like SATA->IDE adapters.

Also CF cards are guaranteed to work on 8-bit machines, but I have no idea if one of these would. That is something to consider depending on the machine you'd like to use it with.

And if I recall correctly, CF cards are slower when writing, while high-class SD cards have better write speeds, which is exactly why SD cards would be more desireable for a Windows machine... which is why wear leveling would be even more important.

alexanrs wrote:

I'd avoid using SD cards altogether on a retro-machine until someone analyses if these controllers have any sort of wear leveling. With CF cards you can pretty much trust a good quality card itself will do it, and that the adapter can only do so much to screw up (since all the logic is in the card itself). With SD cards the controller plays a much bigger role, so there could be some good chips and some crappy ones, just like SATA->IDE adapters.

Also CF cards are guaranteed to work on 8-bit machines, but I have no idea if one of these would. That is something to consider depending on the machine you'd like to use it with.

And if I recall correctly, CF cards are slower when writing, while high-class SD cards have better write speeds, which is exactly why SD cards would be more desireable for a Windows machine... which is why wear leveling would be even more important.

I'm not worried about wearing out a SD card, they are too cheap and all the software/drivers I got backed up. People said the same things about CF when it was new, but I haven't heard anyone say it's been a problem (same goes with SSD drives). You'd have to heavily use the retro computer in a way that would not make any real-life sense over a period of time to get that kind of result.

Anyway, I've ordered a SD to IDE and a Sandisk Extreme (90 mb/sec) 16GB SDcard to bench 😀

alexanrs wrote:

I'd avoid using SD cards altogether on a retro-machine until someone analyses if these controllers have any sort of wear leveling. With CF cards you can pretty much trust a good quality card itself will do it, and that the adapter can only do so much to screw up (since all the logic is in the card itself). With SD cards the controller plays a much bigger role, so there could be some good chips and some crappy ones, just like SATA->IDE adapters.

Also CF cards are guaranteed to work on 8-bit machines, but I have no idea if one of these would. That is something to consider depending on the machine you'd like to use it with.

And if I recall correctly, CF cards are slower when writing, while high-class SD cards have better write speeds, which is exactly why SD cards would be more desireable for a Windows machine... which is why wear leveling would be even more important.

The simple solution is to install plenty of RAM and disable the swap file.

vetz wrote:

I'm not worried about wearing out a SD card, they are too cheap and all the software/drivers I got backed up.

Its about the inconvenience - I myself have little love for the cards themselves, be them CF or SD

vetz wrote:

People said the same things about CF when it was new, but I haven't heard anyone say it's been a problem (same goes with SSD drives).

They all have wear leveling algorithms. I did some googling and apparently higher quality SD cards also do wear leveling on their own, so yours will probably be fine... but this is not part of the spec.

gdjacobs wrote:

The simple solution is to install plenty of RAM and disable the swap file.

Low cacheable limits and apps that crap out without a pagefile do exist. I'd rather enable the "ConservativeSwapFile" option on SYSTEM.INI.