PDA

View Full Version : Fastest PC/XT Disk Setup



pearce_jj
July 9th, 2012, 11:37 PM
We've talked about disk throughput on here a bit in connection with the XT-IDE project(s), but I don't think we've ever had a definitive "the fastest controller available for a PC/XT is ...".

The fastest I've seen disktest (http://www.lo-tech.co.uk/wiki/DOS_Disk_Tester) results for is the Silicon Valley ADP50 (L) (http://stason.org/TULARC/pc/hard-disk-floppy-controllers/S-T/SILICON-VALLEY-COMPUTER-INC-Two-IDE-AT-Interface-d-216.html), which I think does about 315KB/s in an 8088 PC/XT.

In particular, I've never seen results for 8-bit SCSI adapters.

Anyone got an adapter that will do more than 315KB/s?

eeguru
November 10th, 2016, 10:33 PM
Latest run on an IBM PCJr (JR-IDE) with a Raspberry Pi Zero emulating an IDE disk drive:



DiskTest, by James Pearce. Version 2.3

Preparing drive...
Configuration: 4096 KB test file, 256 IOs in random tests.

Write Speed : 332.74 KB/s
Read Speed : 637.01 KB/s
8K random, 70% read : 1.8 IOPS
Sector random read : 1.8 IOPS

Average access time (includes latency and file system overhead), is 545 ms.


However there appears to be something wrong with your timer code on the Jr. I added a byte-rate meter to the transfer logic on the Pi side. While the write speed test was running, it was averaging ~253 KB/s. During the read speed test, it was averaging ~374 KB/s. That's using the clock on the Pi to do all the timing measurements. So I'm pretty sure the 374 KB/s during read is spot on accurate.

After the write phase, all of the target sectors are obviously write-through cached in the Linux unifed block cache despite doing a fdatasync() following each write(). However in my early experience, a random seek to a spot in the image file stored on SD card is pretty minimal. I plan on implementing background read-ahead caching eventually at startup so any irregularities will be moot.

During your mediatest pattern write, I was getting fairly consistent 310-320 KB/s write and 192-196 KB/s read & verify.

The IOPS measurement doesn't seem very useful on a very slow Jr (slower than a 5150 PC). I was consistently getting < 3% duty cycle on servicing IDE commands (< ~1200 bytes/s aggregate rate). So it seem about 10x more effective as a benchmark of the CPU disktest is running on than a benchmark of IDE performance. On a machine where the CPU/IDE time ratio is much lower, it would be a more effective comparison test of one IDE drive to another IDE drive. But since the CPU component cannot be normalized or minimized machine to machine, it is comparing apples to oranges on different processors/speeds.

These numbers are actually better (+20%) than a KingSpec SLC DoM I was using previously. So I'm fairly sure this configuration is the absolute ceiling on fastest achievable I/O performance on any 8-bit PC class machine. It's apparently possible to fill all 736 KB of conventional memory on a PC Jr in under 2 seconds!

There is more information on all this on Mike B's forum. Basically the JR-IDE maps the IDE data register to 256 words of continuous addresses in upper memory so a 'rep movsw' can be used with cx=256 to move a sector in/out with no intermediate instruction fetches. It performs the same 16<->8 bit steering logic that XT-IDE performs. It also adds 1 MB RAM, 512 KB flash, RTC module, and POST display making the Jr a fairly usable machine. I'm currently working on an add-on module that bridges a Raspberry Pi Zero to IDE emulation logic inside of an FPGA via SPI. There are no changes necessary in the JR-IDE BIOS logic. The new Pi module is a turn-key replacement for an IDE disk or DoM. We hope to add WiFi packet driver and SSID support utility in the near future making the Jr a super sexy swinging sound!

All the current JR-IDE code and design files are open-source on my website. (www.retrotronics.org/jride) As will all the code and design files for the Pi Zero module eventually.

pearce_jj
November 10th, 2016, 10:49 PM
Alan, thanks for posting this. I like the idea of the RPi Zero especially!

Re IOPS - the idea of this test was to benchmark real system random IO throughput. As you have determined, wading through the FAT is by far the biggest contributor in an 8088. Interestingly MUCH higher random IO can be achieved with FAT12, so for database applications (if there are any?) multiple FAT12's would be the way to go.

Re throughput; the BIOS overhead is significant contributor. So media supporting longer multi-sector transfers will do better since the BIOS loops happen less.

Trixter
November 12th, 2016, 08:30 AM
The IOPS measurement doesn't seem very useful on a very slow Jr (slower than a 5150 PC). I was consistently getting < 3% duty cycle on servicing IDE commands (< ~1200 bytes/s aggregate rate). So it seem about 10x more effective as a benchmark of the CPU disktest is running on than a benchmark of IDE performance. On a machine where the CPU/IDE time ratio is much lower, it would be a more effective comparison test of one IDE drive to another IDE drive. But since the CPU component cannot be normalized or minimized machine to machine, it is comparing apples to oranges on different processors/speeds.

IOPS is much more important on a slow PC or XT than transfer rate. In fact, I'm working on a project that XT-IDE+CF variants are making possible because I can do 30 IOPS instead of only 3-5 with a traditional hard drive. It is somewhat troubling to me that your test produced 1.8 IOPs when James' boards produce 10-15x that. I would highly suggest looking into that. What kind of IOPs does the jrIDE rev 1 and 2 produce?