Cracking open the Amstrad PC2286, I was surprised to find a Western Digital WD-384R RLL 40MB disk as the few references I can find refer to Seagate disks.  Most likely the original disk was replaced, but an unexpected gem to find the WD disk.  There’s a good history of disks at http://redhill.net.au/d/d-a.html, but basically Western Digital, then a controller manufacturer, bought Tandon to get a disk division to develop drives with integrated controllers – what would ultimately become IDE drives.  Tandons disks were simply re-stickered as Western Digital immediately after the takeover, in this case the TM364 becoming the WD-384.

3.5″ Form-Factor

The TM364’s 20MB 2-head sister, the TM262, was one of the first 3.5″ form-factor drives.  It was a pretty reliable classic RLL stepper-motor drive with somewhat relaxed performance – the specifications quoted 85ms average seek, but measured today with Norton Calibrate in reality even that is somewhat optimistic.  But this unit is still running well 22 years on, which says a lot about its quality.

Bad Sectors and Interleave

Bad sectors were a reality of 1980’s hard drives – internal relocation hadn’t been thought of, and the drives had a handwritten list of known bad sectors on the label.  Once low-level and high-level formatted, an amount of bad sectors would almost always be present, the Amstrad handbook stating 1% of drive capacity as an acceptable range.  With about 100K of bad sectors, this drive is still performing within spec when new today.

Another complication was the interleave, which spaces out sectors so that the CPU has a minimal wait between sectors on sequential operations.  This disk, when operating through the Amstrad PC2286 with it’s 80286 CPU and Western Digital 1006 controller, supports an interleave of 1:1 meaning that an entire track can be read in one disk RPM.

Performance

Hooking up the drive to Intel’s IOMeter was possible by using DOS Networking (LanManger) to share the volume to a Windows 2003 Server, but the performance was awful.  The share performance gave about 60KB/s and 2 IOPS only.  LanManager client performs better – achiving over 20 IOPS from a network share.

Because of this, I devised a simple DOS app to do the same types of tests, DiskTest, which simply performs the three core tests (32K sequential read and write, and 8K random) with a 4MB test file and displays the results.

When testing the random workload, the limitations of the DOS FAT file system were quickly evident, with much slower throughput that I was expecting at just 3 IOPS.  The reason was that DOS kept having to seek to the FAT to find the blocks, and since the FAT(s) are at one end of the disk, this created heavy full-stroke IO load on the disk as the test file happened to be near the other end.  Increasing buffers to 99 solved this, as would installing SMARTDRV with even a small read cache.  With 99 buffers, the results are:

• 32K Sequential Read – 449KB/s
• 32K Sequential Write – 282KB/s
• 8K Random 70% read – 7.1 IOPS

Only 7 IOPS still seems low at first sight, but at these transfer rates and with 70% read, this drive takes on average 21 ms just to transfer the 8K, plus the 105ms to find it, and at 3,600 RPM another 8 ms for the data to arrive – on average, 134 ms.  At 7.1 IOPS, the difference (6 ms on average) is probably then because some of the operations could span two tracks, adding another 15ms, and the odd seek to the file allocation table.

The performance with real apps really does feel lethargic with this drive, but adding a small cache with buffers=99 or SMARTDRV makes a huge difference and software from the time, such as Windows 2, then chug along at a usable pace.