How would one read the graph report with HDDScan? The red graph line that travels across the page starting lets say at 80,000 kbps then slowly descending down until the test is completed. Ending result graph line decreased to about 50,000 kbps after 585,000,000 LBA's. Is this normal, high in the beginning and lower at the end?

I ran the other tests as well and everything is green without errors.

Also, the SCSI log page report shows all green balls in the left hand column but have no idea what the Page num and param numbers really mean. Looks to report the different phases of the test such as "Page num 001 - Param num 000 - Description Buffer under-run - Value 0"

Anyone have a clue how to read this report. My main objective is to test the SAS drive 300GB to make sure it is good. I have 10 to test.

Appreciate any and all input to help understand Thanks

A disc is divided into zones. The outermost zone has the greatest number of bits per track, the innermost zone has the least. Therefore the data transfer rate will be greatest at the outermost cylinders.

See http://hddscan.com/doc/HDD_Tracks_and_Zones.html

Here are HD Tune's benchmarks results for all makes and models of drives:
http://www.hdtune.com/testresults.html

_________________
A backup a day keeps DR away.

It would help if you uploaded the graph image (a picture is worth a thousand words and all that ) but yes, this sounds normal - read about ZBR to see why. The exact values depend on drive model, interface card & OS driver efficiency, I/O block size etc.


This is too big a subject for me to explain everything in detail - Log Pages are described in the SCSI command specs (since SAS drives use SCSI commands), so you can start by looking there if you want to know more. This is one of my specialist areas and really is a huge topic

In brief: Some pages are related to performance (as in the example you gave), some are related to error handling, some to other things (e.g. temperature) etc. etc., but you also need to know how each drive manufacturer (and model) uses the parameters, as they can vary enough to mislead you if you compare dissimilar drives.


You seem to be trying to prove a negative (i.e. trying to confirm that the drives do not have a problem), so I hope you have realistic expectations of what level of confidence you can achieve When I teach troubleshooting to new engineers, the "why can't you prove a negative" lesson is often a lively one


In this brief reply, some suggestions I can think of include:
- Make sure you've done a full read test.
- Check the SMART counters for the usual suspects. Any non-zero value for reallocated sectors or current pending sectors are a special concern (read the public report on Google's data centre drive failures for more details).
- Compare SMART counters and other HDDScan results between the drives - any differences need to be investigated further.
- Looking at the HDDScan graph of read speed (which is what I think you described above), you do not want to see any brief "dips" in that line, even if there are no I/O errors reported.
- Unless all the drives have problems, then my suggestion to compare the results from the different drives, will help you to identify any drives with anomolous behaviours.

I'm sure there are other tests you could do (although the law of diminishing returns will also apply), but I've got to stop now. I hope that helps. Good luck...

Thanks fzabkar and Vulcan.... Much appreciated...

The graph mentioned is located at http://beanzy.shutterfly.com/pictures/9

I see some flutter "dips" in the graph within the first 100,000,000 LBA and again in the 500,000,000 LBA area but not sure if the small dips shown are significant. If they are significant, could other things cause these dips such as other programs running while test is being run?

Thanks - that shows exactly the sort of "staircase" pattern which is expected, due to the ZBR which fzabkar and I mentioned.


Those are not the sharp (i.e. significant) drops in throughput which I was trying to explain would be a concern, if they had been shown (even if such sharp dips were for only a small range of LBAs, which is typically the case). Therefore I am not concerned by that graph.

Hope that info helps.