I believe that the raw 48-bit Seek Error Rate attribute is encoded as follows:
topmost 16 bits = total number of seek errors
bottom 32 bits = total number of seeks
Therefore the Seek Error Rate is equal to ...
(total number of seek errors) / (total number of seeks)
In your case ...
4299089076 = 0x0001003EE4B4
... so your drive has experienced 1 seek error in 4,121,780 (= 0x3EE4B4) seeks.
Seagate drives appear to begin life with an assumed SER of 1 error in 1 million seeks. This equates to a normalised attribute value of 60. If the drive's SER improves, then this value increases, otherwise it falls.
The normalised attribute appears to follow a logarithmic pattern:
90% = < 1 error per 1000 million seeks
80% = < 1 error per 100 million
70% = < 1 error per 10 million
60% = < 1 error per million
50% = 10 errors per million
40% = 100 errors per million
30% = 1000 errors per million
Your current value is 66 which is better than 1 error per million but worse than 1 error per 10 million.
The Raw Read Error Rate appears to reflect a sector count rather than an error rate, although I'm not sure of this as I've yet to see a 48-bit raw value with anything other than 0 in the upper 16 bits.
Anyway here are the results of my investigations:
http://groups.google.com/group/comp.sys.ibm.pc.hardware.storage/msg/030c515959145d44?dmode=source
Based on your results, I expect that the lower 28 bits may reflect a sector count, allowing for 268,435,456 reads. The uppermost bits may hold an error count. The cycle is probably repeated for the next block of 256K reads, and the normalised value is probably incremented or decremented depending on the new error count. However, this is only a guess.
Your current normalised value is 117, which probably suggests that the drive's read performance is improving.
If we use your statistics, then we have 300,000 sectors being read every 6 seconds. This amounts to a transfer rate of 25MB/sec.
Similary, there are 230 seeks every 6 seconds, ie 26ms per seek.
If each seek corresponds to a switch between tracks, then there are approximately 652KB per track, at least in the zone where your testing is being done.
