Error Correcting Code – ECC

Besides advanced data coding methods (for further error-free decoding), hardware and software ECC methods contribute much to the reliability of hard disk drives. Each data sector has traditionally been including a special ECC field, which helps to restore erroneously read data. The use of ECC often helps to read the data even if the read/write head couldn’t position precisely on the track and some of the information got lost. The employed Reed-Solomon code uses some redundant information to provide a higher data reliability than if they were just duplicated!

Regrettably, Samsung has now become as secretive about its products as the other hard disk drive makers, but a few years ago we could learn a few details about the structure of a data sector. Thus, the SpinPoint P20 had 480 bits of 10-way interleaved ECC and 7 bytes of CRC code (13% redundancy) per sector, which allowed restoring up to 10 three-byte errors or one 233-bit error “on the fly”, without compromising the speed. That’s hardware correction – the more sophisticated software processing of the same data allows restoring more, up to 60 bytes, i.e. each ECC bit allows restoring one erroneous bit of the original data at best. Besides the correction codes, each sector contained a 32-bit ESN field (Embedded Sector Number) for the correct work of the ECC generator, while CRC was added, most likely, for a faster identification of errors.

Each manufacturer takes a different approach to the ECC implementation. For example, IBM prefers distributing the code evenly along several sectors in order to have more chances to restore the data in case of a physical damage of a sector. This is the so-called interleave technique with respect to ECC. It is a pleasant surprise that Maxtor and Hitachi still give out information about the structure of the ECC block in their products. For the DiamondMax Plus 9 they specify 320 bits of non-interleaved ECC with cross-validation that allows correcting up to 15 errors, 10 bits each. The Deskstar 7K250 family has 4 interleaved ECC fields, 96 bits each, which allow correcting up to 5 errors to the total length of 153 bits.

With any implementation, the basic characteristic of ECC is the total number of wrong bits that the code can correct. In the characteristics table you saw above I post the specified data for “on-the-fly” correction, i.e. correction without compromising the read speed. As you see, although “thinner” than in the SpinPoint P40, the ECC correction in the P80 remains among the most powerful for today. Seagate (and truant Western Digital) prefer to keep silent about their technologies, but we can get an approximation of the data redundancy by correlating the specified recording density and the media data transfer rate with “end” data-transfer rates, which can be found in the same documentation or measured. Considering that Seagate nearly achieved the point of 60MB/s, like Maxtor but having a much smaller bit density, the amount of housekeeping data (including the ECC code) is very small in Seagate’s drives.

Testbed and Methods

This testing session is wholly about the Samsung SpinPoint P80 series, i.e. I will be comparing models of different capacities, amount of cache memory, and interface (ATA/133 and SerialATA). Thus, we will see the impact of all such factors like the firmware version, cache buffer size and others on the performance of the drive.

We, at X-Bit Labs, have accumulated some statistical data and have files on the following models:

* Regrettably, we didn’t keep the record of the exact firmware version of that sample.

PATA-interfaced HDDs were attached to the Promise Ultra133 TX2 controller (BIOS 2.20.0.14, driver 2.0.0.29). SATA-interfaced drives were tested on the Promise SATA150 TX2 controller (BIOS 1.00.033, driver 1.0.0.27). We also include the results of one drive on the Promise Ultra100 TX2 controller, for illustrative purposes.

The testbed was configured as follows:

• Albatron PX865PE Pro II mainboard;
• Intel Pentium 4 2400MHz (533MHz FSB);
• 256MB PC2700 DDR SDRAM, CL2;
• IBM DTLA 307015 system disk;
• ATI RADEON VE graphics card;
• Windows 2000 Pro SP4.

We used the following benchmarking software:

• WinBench 99 2.0;
• Intel IOMeter 2003.02.15;
• Xbit FC Test 0.5.3.

For WinBench tests we formatted the drives in FAT32 and NTFS as one partition with the default cluster size (FAT32 formatting was performed with Paragon Partition Manager). We ran the tests seven times each, chalking up the best result. The HDDs didn’t cool down between the tests. For the FC Test we partitioned the drive into two logical volumes, 32GB each. For IOMeter tests, we used Sequential Read, Sequential Write, Database, Workstation, File Server and Web Server patterns.

The File Server and Web Server patterns are identical to the ones StorageReview makes use of, and the Workstation pattern was created by us based on the access statistics for NTFS5 as given in the StorageReview methodology. This pattern differs from the server ones in a smaller load range and a higher percentage of write operations (a regular workstation must have much memory, a big portion of which is used by the OS for data caching).