Mike's PCjr Page

2022-04-13: Please read to the end of the thread .. the performance difference has been explained and resolved.

So I gave up on SD Cards because they are fairly cheap devices to begin with, and getting them to work on IDE was kind of "janky."

For my latest experiment I used a StarTech SATA drive to IDE controller adapter and a Kingston 240GB SSD. It's working perfectly, but my initial performance tests are running a little low: 150 to 170KB/sec writes and 240 to 250KB/sec reads. It's more than adequate for the machine, and the SSD should last forever.

As much as I love my hard drives, I think I'm going to start migrating everything over to a setup like this while SATA SSDs are still widely available. They are a much better value than CF cards, which have gotten expensive in the last few years as SD Cards have supplanted them.

150KB/s writes and 250KB/s reads are actually a little above average for an 8088-based system. Unless you're using a controller that uses DMA or a memory window, that's very good performance.

I grabbed 20 4G CF cards from an ebay lot for $30 a few years back. You can get an 8GB CF card on ebay for about $10. SSDs are more bang for the buck, but unless you're going to use FreeDOS and its FAT32 support, the maximum amount of storage you can have in DOS is 24 x 2Gig logical drives for a total of 48G.

Well, that's the problem ... the jrIDE uses a memory window, not I/O registers. I talked Alan into doing that because of REP MOV.

When I measured the SD Card to IDE adapter that eventually flaked out on me I was getting 300KB/sec reading and 220KB/sec writing. And I'm pretty sure that even my 20 year old Maxtor does better than this SSD adapter. I'm going to retest again to ensure that I didn't miss something, but I'm pretty sure of the initial numbers.

I'm not too keen on eBay CF cards - its just too hard to tell how hard they were used. New 4 or 8GB "industrial" cards would be awesome to find now. I just bought a new 32GB SanDisk card, and the Kingston SSD was far more bang for the buck, which is kind of silly.

I somehow missed that the jrIDE used a memory window -- glad it does!

OT, but a quick look back into history:

The memory window was one of the design requirements ...

At the time the XT IDE had the same I/O register layout as an IDE controller, but it was not really compatible with IDE because any command that needed to read data was broken by the requirement to do two 8 bit reads instead of one 16 bit read. The "Chuck" mod to improve performance happened when ChuckG said that if it wasn't going to be IDE compatible, it might as well be faster.

Before even the ChuckG mod though we had a different problem on the PCjr - an IDE adapter was never going to be I/O register compatible because of the PCjr I/O port layout. But I came to the realization that it really didn't matter - my favorite hard drive adapters for the machine were SCSI, and clearly were not IDE I/O port compatible. All we needed was an INT 13 interface. So I did some research, saw the SCSI adapters were using a memory window and the performance benefits of that, and then I sold Alan on the memory window idea when he decided to build a PCjr specific adapter.


Back on topic ...

I might make another attempt at finding "low mileage" CF cards, because in general they work fine. I am a little wary of the wear leveling on CF cards though, and I know a real Disk-On-Module or SSD handles that correctly. This first machine is going to be a web server and it's going to write logs, so wear leveling is important for it. It will probably never generate enough writes to wear out a CF card, so an SSD should last a lifetime.

Is wear-leveling really a concern with this low frequency of IOs? Even old NOR-based cards are rated for 10,000 writes per block, and they perform wear-leveling so it's not dumping all the FAT writes into the same blocks.

As a data point, I've been using the same 512MB CF card since 2004 (Silicon Valley ADP50 adapter) on my daily driver 5160 and have had no issues.

I really don't know ... I know what Disk-On-Modules do and what SSDs do, but Compact Flash had too many price points to rationalize about what each one was doing. Especially on the older, smaller cards that were designed for digital cameras and not as replacements for hard drives.

Take the web server use case for example .. I get at most 250 hits per day. Writing logs out means usually one write per hit because they are not happening fast enough to coalesce the writes. The append to the open log file also causes the FAT to be updated, so you are at two writes now. And these are not 4K writes, so these little updates are about 8x more expensive when you think about it in terms of the amount being written.

I'm going for overkill when I use a new 32GB CF or an SSD, but I know I can never kill it. I could also find a different way to do logging, but that's very workload specific.

Probably for general retro computing use where the machine gets used once a week for a few hours, anything will work. (Remember, I was targeting something I'm leaving on 24x7 and it will be doing writes.)

The PCjr is terrible at keeping time during disk I/O tests - I suspect the BIOS is disabling interrupts for too long. I usually have to do my timing tests with a stopwatch, which is sub-optimal.

I made my timing test slightly more accurate by reading the RTC clock at the beginning of the test and the end of the test. The RTC clock is only good to 1 second, so I wait until the start of a new second before starting a test, and then there is possibly up to 1 second of "slop" at the end of a test. The impact of the inaccurate time can be minimized by running longer tests.

The SSD and adapter combination is as slow as I thought it was. Doing sequential 16KB reads and writes it maxes out at 250KB/sec for reads and 155KB/sec for writes. As a comparison, my 20+ year old Maxtor IDE drive is reading at 320+ KB/sec and writing at 189KB/sec. (All numbers are within 2% of the actual numbers.)

Curious how a CF card holds up under the same testing.

Using the RTC doesn't seem so bad as long as your minimum test reads/writes are over 30 seconds.

Ok, I have an happy update ... it's fast.

My benchmark was bad. On writes it was counting the time for DOS to create a file. It was also probably artificially slow, as DOS has to do housekeeping to keep modifying the FAT as a file grows. I made the following changes:

• When doing a write test, seek to the end of the file and write the last byte. This forces DOS to update the FAT all at once so that it doesn't have to do that during the test as the file is extended.
• Start timing *after* that is done.

The SSD drive had a larger partition, so DOS was doing more work to create the file on writes. It must have been doing some housekeeping on reads too, because both the read and write times improved.

Using a 10240 KB file for the test, the new numbers are:

• 20GB Maxtor: Write: 36 seconds (284.4 KB/sec), Read 32 seconds (320.0 KB/sec)
• Kingston SSD on a StarTech SATA to IDE adapter: Write 36 seconds (284.4 KB/sec), Read 31 seconds (330.3 KB/sec)

These timings can be off by up to a second because I'm using the real time clock. At worst case (a full second of error) the writes will only be 276KB/sec, while the reads will be closer to 310 or 320KB/sec.

So the next mystery is to try to figure out why the Kingston read speed improved. (I tested both devices on the same machine this time to keep things consistent; I might have screwed up and compared a NEC V20 to an 8088 in my previous report.)