OK, did some web research. ATA/33 in UDMA mode has a bandwidth of 33MB/s. So, to get the best speed possible in a CF adapter, you need an adapter that supports UDMA mode. You also need a CF card that is UDMA compatable with a 500x speed (if you wish to maximize the write speed as well as the read.) Most of the cards I looked at that gave the sequential speeds (and I found this strange,) gave stats that were reversed... So the 500x's 80MB/s Read and 40MB/s Write speeds, became 40MB/s Sequential Read and 80MB/s Sequential Write. Didn't find that many that actually gave the sequential stats though. Almost all gave just the normal Read/Write, and many gave just the Read. Now, 400x may also work as that is 75MB/s Read and 30MB/s Write. Which is very close to the 33MB/s bandwidth limit.

The stuttering and pauses are caused by low write performance with small files, not interface bandwidth or sequential data rates. Cheap flash devices tend to drop to floppy-like speeds when doing numerous small writes. This even includes some older SSDs.

A solution I've seen for getting around horrible write performance of cheap flash devices is to use a large write behind cache of some sort. For example, there was a driver for Windows XP called Flashfire that did this. It used something like a 32MB RAM cache for writes and was very helpful for the early EeePC with its CF-based "SSD". The downside is a risk of extreme filesystem corruption if power or stability is lost before writes to the drive finish.

Also, ATA data rate specs are the theoretical max. You will see around 25MB/s max in practice with UDMA 33.

Well, that is why I said that the 400x should be fine. But if you want to take advantage of those times when it might actually peak a bit, then go with the 500x. I've not really noticed a big difference in prices between the 2, I've even come across some 600x that are competitive. All this actually started when I was wondering what the best adapter/card combo's would be best. I discovered that the adapter was UDMA ATA/33 only (though I came across a highly risky patch that is supposed to raise that.) So, I started looking at the specs for ATA/33 and researching how to find CF cards that would be most compatible without wasting performance.

As far as read/write caching, that's has been a solution for slower bus/device speeds for ages. Since DOS 5 I think, or whenever smartdrive made its appearance. From what I understand, write caching is on by default in Windows 98SE+, thus the "Safely Remove Device" option everyone is "supposed" to use before removing USB storage devices. Most modern HDDs have built in fast RAM caches as well, to make up for the mechanical seek times, and read/write delays, as bus speeds are pushing these drives well past their mechanical limits.

Cannot really comment about small file writes, as I really have no direct experience with CF cards (all my info is from web research.) I'm wondering if the benchmark test program ran at the beginning of this thread used small file or sustained file (large file,) for it's testing? It was the results of that test that started this thread in the first place, I believe. But it seems to me that you could avoid this fault by sticking with reliable brands (though it would cost more.)

FeedingDragon wrote:

nforce4max wrote:

Not all CF cards are crappy like this, I had a 32gb card on a ibook G3 and it performed much better than this. Also if you know which CF cards are better you would know which ones that were SLC and were quicker 😉

You wouldn't happen to know which CF cards are good would you?

Also, on a side note, every single adapter I could find anywhere were only ATA/33 compatible. Not 66, 100, or any PIO mode. Isn't that the slowest IDE speed? It seems that this would give CF adapters a handicap right from the start. Now, there was an article or something I read somewhere about disconnecting a pin on the adapter and connecting it somewhere else, upping it to ATA/66, but that it was risky.

I have this very same adapter with the jmicron 20330 chipset and it works perfectly on a DFI KT333 board with both 500GB and 1TB samsung f3 drives running at ATA/100

I'm currently playing with my P3 1.4S system (VIA chipset) and having Windows 98SE on a 4GB Microdrive.

Are there any benchmarks (HDD) you want to me to run?

If so, please provide links to make it easier 😀 W98SE isn't my area of expertise and I often find tools which then don't run on this OS.

Mau1wurf1977 wrote:

I'm currently playing with my P3 1.4S system (VIA chipset) and having Windows 98SE on a 4GB Microdrive..

That's a Tualatin right? What board are you running and is it the pin-modded version or the real deal? I've been thinking about trying my pin-modded 1.4S in a new build, as I think it should work in my Asus CUSL2.

No mod it's a proper Tualatin board from Gigabyte.

There is more info in that "replacing capacitors" thread. I did the replacement this afternoon 😀

Artex wrote:

Can you shed some light on this for me? I'm afraid I'm not familiar..

Flash chips use erase blocks that must be erased in full unlike (traditional) hdds that operate in 512b sectors. The size depends on the flash chip used and can be as large as 64K. The newer advanced format hdds with 4K sectors work very slowly when partitions are not 4K aligned since each read or write will need to work on 2 sectors at once (and sequential write would mean that each sector would have to be written twice for each unaligned access). Now, modern filesystems work mostly with 4k blocks so that usually perfectly aligns with 4k sectors and properly aligned partitions.

I've refreshed my memory a bit and remembered that fat32 actually uses only 512b clusters. That means that access would only occur with 512b blocks and that would certainly be slow. An interesting test would be to have a fat16 partition with larger clusters (perhaps 16 or 32k) and properly aligned partition...

gulikoza wrote:

I've refreshed my memory a bit and remembered that fat32 actually uses only 512b clusters. That means that access would only occur with 512b blocks and that would certainly be slow. An interesting test would be to have a fat16 partition with larger clusters (perhaps 16 or 32k) and properly aligned partition...

FAT32 uses 512 byte clusters only with partitions of <= 64MB.
http://support.microsoft.com/kb/140365

When the partition alignment issue came to my attention, I aligned my EeePC's Windows XP partition. Honestly I am not sure if it was a tangible improvement. It certainly isn't a solution to write performance problems. One thing that did help was using non-journaling filesystems like EXT2 or FAT32 because that reduces write frequency. Combining that with a caching driver like Flashfire made it quite fast overall, but I managed to trash the filesystem once when I lost power. The best solution is dumping the slow flash hardware.

FeedingDragon wrote:

... Most modern HDDs have built in fast RAM caches as well, to make up for the mechanical seek times, and read/write delays, as bus speeds are pushing these drives well past their mechanical limits ...

SSDs do have DRAM caches too, memory caches greatly speed up any storage drive. In fact some SSDs contain nowadays a larger amount of RAM in their caches than our whole systems had 10~15 years ago 😀 , the top left chip in this Samsung 840 EVO mSATA is the 1GB DRAM cache:

Artex wrote:

... I've been thinking about trying my pin-modded 1.4S in a new build, as I think it should work in my Asus CUSL2.

It works, combat proven. Easier than hacking Slot-1 mobos as only the CPU needs retouching.

The flash animation in here helps to visually understand partition alignment: http://www.paragon-software.com/home/partition-alignment/

@ Swaaye I'm unable to find a download link for that Flashfire caching software, is it defunct perhaps?

I've been using Fancycache (now Primocache) for years, works like a charm.

Still doing research in CF cards as HDD's. As a note, I thought that was what we were talking about here. SSDs, technically, should be considered more of a HDD, than a CF card, as they are already designed to work as such (instead of needing an adapter.) Yes, I know SSD's generally have cache RAM as well, but IDE to CF adapters generally don't have this, though I think they really should.

I've made another interesting discovery. When picking out a CF card for the adapter, you need to look for ones that are SLC (Single Level Cell,) instead of MLC (Multi,) or TLC (Triple,) which determines how many bits are stored in each memory cell (usually determined by differing voltage levels for M & T.) With HD style reading/writing, the SLC is faster and much more stable. With the limits of the ATA-33 interface, most SLC cards max it out with 233x or 300x. Achieving very close to the same speeds as an HDD on a ATA-33 port.

I've come across another issue as well, which might lead to actually getting a SD to CF adapter and using an SD card instead (haven't started researching that yet.) CF cards are rated as only accepting 1,000,000 writes per cell before cells start failing. I don't know how accurate that is, but it really doesn't sound good on a computer you plan to use regularly. Also, with CF cards, cells are written to faster if they are cleared when they are made available (files are erased/written over.) The smarter, more modern (ie: expensive,) cards have systems built in to adjust for both of these. Always re-mapping the cells so that a new cell is written too every time, automatically clearing cells that are re-mapped as free, etc.... This will extend the life of the card (probably by quite a bit,) and allow the card faster writes, but I still don't really like the 1,000,000 write limit.....

edit: Also forgot to mention that for HDD use, CF cards built on NAND gates are better than ones built on NOR gates, NAND is better at single bit reads (which is how HDDs work.)

edit2: Correction, the number is 100,000 not 1,000,000... My bad, sorry about that. The standard is the same for SD cards (100,000 write cycles before cells start going bad.) The only advantage I could see in an SD card is that they are generally cheaper (on the searches I did,) and faster than the CF cards. But the adapter runs around $10-$20 which could mitigate the lower cost of the SD card.

^This is why i'm using industrial grade SD cards, which are SLC NAND based.

FeedingDragon wrote:

... there was an article or something I read somewhere about disconnecting a pin on the adapter and connecting it somewhere else, upping it to ATA/66, but that it was risky.

If we ground IDE pin 34 (PDIAG#) this 'cheats' that an 80 conductor wire is present, and the limitation to UDMA-2/ATA-33 is lifted.

However there is a chance that crosstalk will ruin the party.

carlostex wrote:

^This is why i'm using industrial grade SD cards, which are SLC NAND based.

Which ones?

Too much talking, I want to see some benchmarks of your storage solutions 🤣

I'll start with an easy score to beat!

This is a 4GB Hitachi Microdrive on a Pentium III-S 1.4GHz with 256MB Ram.

The benchmark can be downloaded here:

http://www.roadkil.net/program.php?ProgramID= … wnloadVersion=2

Where are the random write scores?

It's read only I believe...

Mau1wurf1977 wrote:

It's read only I believe...

Gotcha.. I think it's the random/sequential writes, especially for small files, that are the primary concern.

What did you run? SiSoft Sandra?

If it can also test a secondary drive I test all sort of drives I got floating around 😀

Artex wrote:

Good point.. Interesting, I guess I never knew they made PATA SSDs. I wonder if something like this would suffice...just don't like off-brand stuff. 😜

http://www.newegg.com/Product/Product.aspx?It … =9SIA1K60RX7180

KingSpec 1.8-inch PATA (IDE) Solid State Disk SSD. 44-pin IDE interface, 32GB capacity and supporting speeds of up to 105MB/sec (read) and 60MB/sec (write).

wow... I had just assumed that no one made IDE SSD's. Gives me something to consider instead of buying a few refurb 120GB ATA100 drives.