@maxtherabbit
Thanks. I also use MM for testing 486 PCI hardware most of the time.
Just looked-up some of the Quake 1 and disk i/o numbers for 486 PCI motherboards i posted in the past.
We are all in the ballpark.

@Feipoa
I tested with your UUD BIOS version (2014), as i assumed you use that. Notice the screenshot i shared above.
Picture of the CF card attached - Sandisk Ultra 16Gb 50Mb/s.
Checked briefly with Transcend 4Gb 133x - the orange one - results were the same.
I don't have any Cyrix 5x86 CPUs.

According to ATTO the disk write speed is better with the custom UMC driver.
Not sure why WinTune2 really didn't like it.
Looks like it depends on which test you ask.

Will check PIO-3 vs 4 in a few.
The setup is still on the bench, so should be quick.

Those results are really odd with the ATTO. For a 128K block size, you get 9118 KB/s read, but for 1024K, you are down to 4008 KB/s, but for 4096K, you are back up to 9782 KB/s. I don't normally see the results go up and down like this. And the Write speeds are consistently poor, worse than mine in fact. Something smells fishy with the UMC driver.

So when you are using the Windows driver, you don't see those 10 MB/s speeds until the block size is 4096 KB. The sharp rise in throughput from 2048K to 4096K is not typical. Also, I wonder why your write results are so poor...

Do you have a screenshot showing how your CF card is setup in the BIOS, cylinders, sectors, etc? Using LBA, LARGE, NORMAL, etc. I've found that some CF cards larger than 8 GB just won't work properly even if you identify them in the BIOS as 8 GB with correct attributes for 8 GB.

No Cyrixes - OK, are you able to test at 133 MHz then?

Ugh, i captured the ATTO numbers with BIOS set to 3-2-2-2 and DRAM wait states set to 3.
Fixed and updated the images. So the numbers reflect the most optimal timings in the BIOS (as seen in the previously attached screenshot).
Doing multiple things at the same time, so stuff like that happens when not paying attention.

As for DOS test in SpeedSys with varying PIO-3/4/AUTO.
UMC DOS driver seems to take business into its own hands, so BIOS settings don't matter. Reported metrics are the same.
What you see in the attached screenshot is with disk speed set to 17. Things seems to work, but i see a note in the config.sys to keep it at 10.
Looking at what i reported on page 3 based on the thorough testing of the Biostar UUD motherboard - numbers there are lower - based on disk speed 10. Thinking about it now - there were some stability issues, but cannot remember what exactly.
Leaving it to you which number to believe. I would go with the one based on speed 10 - i know that i do my homework on stability. 😉

The CF cards i use are hand picked - they work well.
Sandisk Ultra cards are used with late 486 motherboards and later.
Using them in LBA mode - whatever the BIOS sets there.
Can provide screenshot later if you want.

---

Can do AMD 5x86 at 133Mhz test tomorrow (5x86 Cyrix'es give me bad memories )
But what you are after here ?!
😀

pshipkov wrote on 2021-06-21, 07:16:

But what you are after here ?!

I am starting to wonder if there is a large dependency on the PCI frequency. I am also starting to wonder if the UMC driver has issues with Cyrix 5x86 CPUs.

You are running your ISA bus at PCICLK/2, so 20 MHz. Why? I am unable to run mine that high when the FSB is at 66 MHz. I must set my PCI bus to 33.33 MHz for the system to boot. But I did do some testing with the ISA divisor. With the ISA clock at 8.33 MHz, the Speedsys buffered read score is 4750 KB/s. With the ISA clock at 11.11 MHz, the score is 4800 KB/s. With the ISA clock at 16.7 MHz, the score is 4850 KB/s. Small, but the dependency is there. I bet the PCI dependency is even more extreme.

Also, my L2 wait states are at 3-2-2-2 due to the FSB setting.

With ATTO, looks like your average max speed is around 6000 KB/s. It is odd to have an outlier at 9000 KB/s for 2048 KB block size. Why is this happening?

Does your SanDisk Ultra support multi-sector transfers?

Yes, could you please share your HDD BIOS setup screen? I put a 32 GB SanDisk Extreme Pro 32 MB UDMA7 card in the system and I get really odd values when I autodetect HDD, e.g. disk size is something silly like "P014". Did you find the newer SanDisk cards to not work as well?

For the UMC driver, are you using v3.1 for DOS and v3.2 for Windows? The ATTO Windows benchmarks with the UMC driver are peculiar. I don't normally see the speeds bouncing around like that and I recently HDD benched about a dozen of my systems.

I assume you using the 5V setting on your CF-IDE adapter and not the "power-over-IDE" jumper for 3.3V? Does the IDE port on this MB even supply 3.3V to IDE header (I think pin 20)? I can't imagine it would.

You mentioned that the standard windows driver doesn't have the DMA option persist, but is there such an option with the UMC driver? How are you getting 23000 KB/s? PIO-4 doesn't even support that kind of speed. Would you be willing to take a stop watch measure the real-world bandwidth with some, say, 200 MB files? Ideally, you'd want to go from something with UltraDMA speeds onto the CF card, and from the CF card back to the UDMA controller. Then try from Primary IDE to Secondary IDE. Record the values. I'll do the same on my system and we can compare the results.

I think it is going to take quite some time to figure out exactly what is going on here.

EDIT:
I transferred two files of type mpg, with sizes 29,699 KB and 132,617 KB.

From Promise UDMA100 PCI card to IDE PIO-4 = 2750 KB/s and 2822 KB/s -------> average = 2786 Kbyte/s

From IDE PIO-4 to Promise UDMA100 PCI = 2475 KB/s and 2550 KB/s ------> average = 2512 Kbyte/s

Notice how these results aren't even close to the 4,000 KB/s reported by ATTO for a 8,192 KB block size

.

feipoa wrote on 2021-06-21, 10:14:

You are running your ISA bus at PCICLK/2, so 20 MHz. Why? I am unable to run mine that high when the FSB is at 66 MHz. I must set my PCI bus to 33.33 MHz for the system to boot. But I did do some testing with the ISA divisor. With the ISA clock at 8.33 MHz, the Speedsys buffered read score is 4750 KB/s. With the ISA clock at 11.11 MHz, the score is 4800 KB/s. With the ISA clock at 16.7 MHz, the score is 4850 KB/s. Small, but the dependency is there. I bet the PCI dependency is even more extreme.

Why PCICLK/2 at 20 ?
These are the "default" settings i use for 40MHz FSB.

feipoa wrote on 2021-06-21, 10:14:

Also, my L2 wait states are at 3-2-2-2 due to the FSB setting.

At 60MHz FSB i am able to run at 2-2-2-2.
Need to check 66MHz, but pretty sure it was the same.

feipoa wrote on 2021-06-21, 10:14:

With ATTO, looks like your average max speed is around 6000 KB/s. It is odd to have an outlier at 9000 KB/s for 2048 KB block size. Why is this happening?

In my humble opinion, these disk tests are flaky to start with.
Best approach is to time read/write a big file and then series of small files.

feipoa wrote on 2021-06-21, 10:14:

Does your SanDisk Ultra support multi-sector transfers?

Yes.

feipoa wrote on 2021-06-21, 10:14:

Yes, could you please share your HDD BIOS setup screen? I put a 32 GB SanDisk Extreme Pro 32 MB UDMA7 card in the system and I get really odd values when I autodetect HDD, e.g. disk size is something silly like "P014". Did you find the newer SanDisk cards to not work as well?

Faster rated CF cards don't always equate to better performance with retro hardware.
Some of my findings around that here.

feipoa wrote on 2021-06-21, 10:14:

For the UMC driver, are you using v3.1 for DOS and v3.2 for Windows? The ATTO Windows benchmarks with the UMC driver are peculiar. I don't normally see the speeds bouncing around like that and I recently HDD benched about a dozen of my systems.

Yes 3.1 for DOS and 3.2 for Windows95.
If you squint your eyes a bit - the write speeds have similar distribution across the chunk sizes for both drivers. With the sweet spot being around 64/128Kb.
Read speeds are more volatile with the UMC driver, but still resemble the more smoothed results of the default one.
Some unrealistic values there going beyond what PIO-4 can do and some other are too low ...
But the most suspicious thing between the shared numbers is that your read speeds are actually lower than the writes. If i can make a prediction - a CF card that is not ideal for the retro rust in use.

feipoa wrote on 2021-06-21, 10:14:

I assume you using the 5V setting on your CF-IDE adapter and not the "power-over-IDE" jumper for 3.3V? Does the IDE port on this MB even supply 3.3V to IDE header (I think pin 20)? I can't imagine it would.

Didn't measure any pin voltages, but no perf difference between the two states here.

feipoa wrote on 2021-06-21, 10:14:

You mentioned that the standard windows driver doesn't have the DMA option persist, but is there such an option with the UMC driver? How are you getting 23000 KB/s? PIO-4 doesn't even support that kind of speed. Would you be willing to take a stop watch measure the real-world bandwidth with some, say, 200 MB files? Ideally, you'd want to go from something with UltraDMA speeds onto the CF card, and from the CF card back to the UDMA controller. Then try from Primary IDE to Secondary IDE. Record the values. I'll do the same on my system and we can compare the results.

I provided a screenshot of what the options of the UMC driver dialog are. No DMA setting.
There is a "synchronize" one, but it does not persist between restarts.
Who knows how this large read value happened. Most likely a flakey test suite, or some magical caching between UMC driver and CF controller.
Sure, i can stop-watch it.

Are you willing to share an image of the BIOS screen showing your CF card setup on the standard setup page?

I have tried a generic no-brand CF card and the ATTO benchmark results weren't any better. Maybe I should source a SanDisk Ultra 50 MB/s to be sure. Do you have a screenshot that indicates this card really does support multi-sector transfer? NSSI or HWINFO should display this information.

I would be really surprised if you and fully stable at 2-2-2-2 at 66 MHz.

I'm looking forward to your stop watch tests. I did mine under NT4.

Just tweaked some of the wording in my previous post for better clarity.

Sure, will provide a screenshot of the IDE settings and some timed read/write results, but that will be in the evening. Need to look busy now.
If you can send me your test files - that will be good, otherwise i can create 0-filled ones to the size you specified.

I shut down my HTTP and FTP servers years ago, so not sure how to send these files to you. I suggest using any mpg files of sufficient size. I doubt the different encoding schemes will have that much difference on the transfer rates. EDIT: Oh, maybe IRC? DCC transfer used to be the thing in the mid 90's, but I haven't really tried it recently.

Have you compared the variety of Transcend drives? Seems like they come in all sorts of industrial grades, like 100I, CF160, CF170, CF300, CF220I, etc. Some have ECC built-in and an erase counter, and too many others to name. Seems like the more the card is trying to do the slower the performance might be on a slow system.

Did you find the traditional Transcend 133x rainbow coloured cards to be the most compatible, or the fastest on 386/486 systems?

4x40MHz
same optimal BIOS settings from previous post
64Mb FPM RAM
256Kb L2 cache
One of the Biostar UUD rev.2 boards.
Blank drive D with one file in it - new FAT16 partition 504Mb in size - meaning no fragmentation, at least on OS level (no idea how data is being actually stored inside the flash memory, since its controller is supposed to scatter it around to average wear)
no caching techniques (smartdrive, etc)
1 file - 110,950,971 bytes in size

Windows 95 OSR2, default IDE driver: 43.53 seconds = 2,489Kb/s
Windows 95 OSR2, UMC controller: 72.34 seconds = 1,498Kb/s <- meh
DOS, UMC driver in speed 17 (highest): 48.83 seconds = 2,219Kb/s

This how the BIOS perceives CF's topology.

Never spent the time and $ to find out who is who in the CF's world in relation to retro hardware.
From the bunch of different CF cards (we can say 10-12'ish different models) the 3 i shared in my previous post worked best.
There may be better ones out there, but so far these 3 cover my needs pretty well.

For Transcend CFs - i tried two more models - one was blue and another one uniform in orange color - they were not better than the x133 one for the 286/386 and early 486 PCs. Need to check on exact models if you are interested.

The small formats CF cards are sort of equal and often worse than their bigger size cousins.

But this is based on personal incomplete observations, so take these notes for what they are.

Thanks for the HDD BIOS screenshot. What is size @015 and how does this show up in DOS? Mine was size "P014" and it didn't work properly.

Looks like the UMC driver is junk. What is the non-UMC driver's DOS performance like?

What non-CPU bound DMA controller did you use to help facilitate the transfer - also a Promise Ultra100? If you want from MB IDE to IDE, either via slave or the secondary port, then wouldn't the CPU be working extra hard, and this would explain your lower performance?

I read in the BIOS Companion that LBA might be slower than LARGE on older systems. Thus I wonder, if a HDD has has been setup with LBA (e.g. in Windows) and the user then changes it to LARGE in the BIOS, will it still work properly without reinstalling the OS?

feipoa wrote on 2021-06-22, 06:44:

What is size @015 and how does this show up in DOS? Mine was size "P014" and it didn't work properly.

It is 16gb model cf.
Or I may not understand your question.

feipoa wrote on 2021-06-22, 06:44:

Looks like the UMC driver is junk. What is the non-UMC driver's DOS performance like?

Win95 umc driver is troubled, but the dos one is ok.
Without dos driver perf is dismal. Something like base level isa ide. Never timed it like what we did here, but speedsys reports something like less than 4mb/s linear read, basically less than half the numbers with driver on.

feipoa wrote on 2021-06-22, 06:44:

What non-CPU bound DMA controller did you use to help facilitate the transfer - also a Promise Ultra100? If you want from MB IDE to IDE, either via slave or the secondary port, then wouldn't the CPU be working extra hard, and this would explain your lower performance?

So far I used only the on-board umc controller.
I think this was the point of the excersise, otherwise we will be profiling completely different hardware, which has nothing to do with the controller in question.

feipoa wrote on 2021-06-22, 06:44:

I read in the BIOS Companion that LBA might be slower than LARGE on older systems. Thus I wonder, if a HDD has has been setup with LBA (e.g. in Windows) and the user then changes it to LARGE in the BIOS, will it still work properly without reinstalling the OS?

BIOS abstracts the hdd config, so we can switch between these settings at any time without side effects, as long as we don't spill outside their related maximum address space. Big books say that lba may be marginally faster, but I am yet to see that.

feipoa wrote on 2021-06-21, 20:53:

Did you find the traditional Transcend 133x rainbow coloured cards to be the most compatible, or the fastest on 386/486 systems?

Yes. They are especially good for DLC CPUs in highly optimized 386 systems.
There write access issues occur often with other CF models.
Also, perf is better.

Similar is the situation when using DLC upgrades in 286 systems.

pshipkov wrote on 2021-06-22, 07:10:

feipoa wrote on 2021-06-22, 06:44:

What is size @015 and how does this show up in DOS? Mine was size "P014" and it didn't work properly.

It is 16gb model cf.
Or I may not understand your question.

Your BIOS HDD screen shows a size of "@015". The BIOS has an 8 GB limitation. What size does your HDD show up as in DOS with and without the UMC driver? I assume you aren't using the XTIDE BIOS to extend the 8 GB limitation? For my 32 GB card, using an auto detection method like you have done doesn't work out (CF card not readable in DOS). My 32 GB drive, for example, show sup as "P014" when I use the auto detection feature in the BIOS.

feipoa wrote on 2021-06-22, 06:44:

What non-CPU bound DMA controller did you use to help facilitate the transfer - also a Promise Ultra100? If you want from MB IDE to IDE, either via slave or the secondary port, then wouldn't the CPU be working extra hard, and this would explain your lower performance?

pshipkov wrote on 2021-06-22, 07:10:

So far I used only the on-board umc controller.
I think this was the point of the excersise, otherwise we will be profiling completely different hardware, which has nothing to do with the controller in question.

Not sure I agree with that. Do you have a Promise Ultra66, Ultra100, or Ultra133 and are willing to humour me? CF-IDE to CF-IDE is not something I would setup in a system. I'm trying to simulate large file open/read speed on a system setup with a single CF-IDE card. It may also see some large sized file transfers (read/write) over the network.

Unfortunately, I am not able to test IDE-to-IDE on my system because I do not have a CF card that is 8 GB or less with Windows 95 or NT installed. I have a 32 GB one with w95/NT4 installed, but as noted above, I cannot get the system to work/boot with it when plugged into the MB's IDE port. I probably need the XTIDE BIOS setup for thus, but am waiting for parts. I have two 8 GB cards which get recognised properly, but they have systems setup on them and I don't want to wipe them. I need to order more CF cards, hence all the CF card questions.

Is this any help?

https://www.target-earth.net/wiki/doku.php?id … mory_benchmarks

A few months ago I went through all of the CF and SD cards in my "box of flash memory" and benchmarked them using the Linux 'disks' tool. The Sandisk 'Extreme' branded ones all had a higher write performance than other cards at the same capacity and read-speed.

My preference is for Sandisk Extreme and Ultra (as per @pshipkov's example above) as they are good quality, can still be bought new and are pretty fast under a modern OS to transfer stuff to. That said, copying Dos content over they all suck, due to the lack of cache and the hundreds of small files that Dos games tend to have - performance takes a nose-dive at that point, regardless of how fast their low level transfer rate.

pshipkov wrote on 2021-06-22, 07:10:

BIOS abstracts the hdd config, so we can switch between these settings at any time without side effects, as long as we don't spill outside their related maximum address space. Big books say that lba may be marginally faster, but I am yet to see that.

Well, there is a 1 MByte difference in size reported in the BIOS when the HDD is setup as LBA vs, LARGE. If you are using LARGE and for sake of simplicity, you've filled up the 8070 MB. Then switch to LBA, you'll be missing 1 MByte worth of data from some file or files, would you not?

megatron-uk wrote on 2021-06-22, 07:46:

Is this any help? […]
Show full quote

Is this any help?

flashmemorybenchmarks.png

https://www.target-earth.net/wiki/doku.php?id … mory_benchmarks

A few months ago I went through all of the CF and SD cards in my "box of flash memory" and benchmarked them using the Linux 'disks' tool. The Sandisk 'Extreme' branded ones all had a higher write performance than other cards at the same capacity and read-speed.

My preference is for Sandisk Extreme and Ultra (as per @pshipkov's example above) as they are good quality, can still be bought new and are pretty fast under a modern OS to transfer stuff to. That said, copying Dos content over they all suck, due to the lack of cache and the hundreds of small files that Dos games tend to have - performance takes a nose-dive at that point, regardless of how fast their low level transfer rate.

Unfortunately, many of these in the smaller sizes are getting harder to find new. The 8 GB size is desirable for the obvious reason of BIOS limitation. If the XTIDE BIOS works well with my system, I'll probably source a 64 GB SanDisk Extreme 160 MB/s, but was also looking at the Transcend CF160. In the mean time, I'm trying to source some 8 GB cards still new. Am going to go for the rainbow Transcend 133x, SanDisk Ultra 50 mb/s, and maybe a Transcend industrial CF170 8 GB.

feipoa wrote on 2021-06-22, 07:39:

Your BIOS HDD screen shows a size of "@015". The BIOS has an 8 GB limitation. What size does your HDD show up as in DOS with and without the UMC driver? I assume you aren't using the XTIDE BIOS to extend the 8 GB limitation? For my 32 GB card, using an auto detection method like you have done doesn't work out (CF card not readable in DOS). My 32 GB drive, for example, show sup as "P014" when I use the auto detection feature in the BIOS.

I see. Will clarify tomorrow.
I remember issues like that with som CF cards.

feipoa wrote on 2021-06-22, 06:44:

Not sure I agree with that. Do you have a Promise Ultra66, Ultra100, or Ultra133 and are willing to humour me? CF-IDE to CF-IDE is not something I would setup in a system. I'm trying to simulate large file open/read speed on a system setup with a single CF-IDE card. It may also see some large sized file transfers (read/write) over the network.

Yeah, I have several pci local storage controllers - promise, sis, 3ware, adapte, etc.
Local storage operations within the same drive and controller are the most common ones by far.
Specific use cases can be arranged to take advantage of spreading the pain between different controllers and drives, of course.
But better setup raid if want to avoid the perf bottlenecks of basic ide setup with these old systems, than hacking around with individual drives/controllers.
With that said - since we are on a journey already I will follow you here - pickup a controller and tell me what test to run with it.

feipoa wrote on 2021-06-22, 06:44:

Unfortunately, I am not able to test IDE-to-IDE on my system because I do not have a CF card that is 8 GB or less with Windows 95 or NT installed. I have a 32 GB one with w95/NT4 installed, but as noted above, I cannot get the system to work/boot with it when plugged into the MB's IDE port. I probably need the XTIDE BIOS setup for thus, but am waiting for parts. I have two 8 GB cards which get recognised properly, but they have systems setup on them and I don't want to wipe them. I need to order more CF cards, hence all the CF card questions.

Ugh.
I would get compatible CF cards and don't bother with the xt ide nonsense.

megatron-uk wrote on 2021-06-22, 07:46:

Is this any help? […]
Show full quote

Is this any help?

flashmemorybenchmarks.png

https://www.target-earth.net/wiki/doku.php?id … mory_benchmarks

A few months ago I went through all of the CF and SD cards in my "box of flash memory" and benchmarked them using the Linux 'disks' tool. The Sandisk 'Extreme' branded ones all had a higher write performance than other cards at the same capacity and read-speed.

My preference is for Sandisk Extreme and Ultra (as per @pshipkov's example above) as they are good quality, can still be bought new and are pretty fast under a modern OS to transfer stuff to. That said, copying Dos content over they all suck, due to the lack of cache and the hundreds of small files that Dos games tend to have - performance takes a nose-dive at that point, regardless of how fast their low level transfer rate.

Hell yeah - this sure is a great info.
Thanks for sharing.
Let me digest it properly.

Should we try to choreograph some cross benchmark in let's say DOS and some popular 486-correct version of Windows, like 98 or 95osr2.
Can be as simple as hand stopwatching a copy of ### mb file.
We can pick boards that are close/compatible. Even hw setup varies a bit, we will still have more info than we have now. 😀