Disk read speed benchmark wanted

[Mark Fineman]

I am looking for a disk read speed benchmark that will scan the
entire disk while running under Windows XP Professional and
allow me to see when a reallocated (revectored, replaced, whatever)
sector was reached.

I have used DiskSpeed32 Version 3,0,0,5 from
Victor M. Grinenko at www.geocities.com/vgrinenko.
It is a couple of years old.

It is accurate enough so that I can see when the
number of sectors per track changes (by looking
at the local peaks), but the range in speed is
more than 20%. I am not sure if this is reflecting the
actual performance of the drive or if it is due to being
too far from the hardware or some operating system interaction.

In the past (when 1 GB was $10K) I could tell when a revectored
block was reached because I could see a performance hit for a
replacement block in the same cylinder and a bigger hit for a
replacement block at the end of the drive. The speed variation from
track to track was less than 1%. On some, but not all, drives I
could see the delay for head switching between cylinders, but there
were 19, 38, or even 76 tracks in a cylinder, rather than 2, 4, or 8
and the in drive buffers were much smaller, so normal track switches
and cylinder switches might not be vi sable now. If anything, I would
expect the drive to figure out that I was reading sequentially and
hide variations more so that I would only see delays for soft errors,
but instead I see a 20% variation.

 

[Rod Speed]

I am looking for a disk read speed benchmark that will
scan the entire disk while running under Windows XP
Professional and allow me to see when a reallocated
(revectored, replaced, whatever) sector was reached.

That last is very difficult to do at the Win level.

Easier done at the dos level.

I have used DiskSpeed32 Version 3,0,0,5 from
Victor M. Grinenko at www.geocities.com/vgrinenko.
It is a couple of years old.

And has some real problems in some situations. There
is often only the roughest similarity with what HDTach
reports and HDTach appears to get it right better.

It is accurate enough so that I can see when the
number of sectors per track changes (by looking
at the local peaks), but the range in speed is more
than 20%. I am not sure if this is reflecting the actual
performance of the drive or if it is due to being too far
from the hardware or some operating system interaction.

Its basically due to the OS making it hard for anything
to show the read speed accurately because of what
else is going on. Thats what produces the variation.

In the past (when 1 GB was $10K) I could tell when a
revectored block was reached because I could see a
performance hit for a replacement block in the same cylinder

That approach isnt used anymore.

and a bigger hit for a replacement block at the end of the drive.

And that is only seen with sectors that have gone bad over time.

The modern approach is to allow for the bads in the
mathematical conversion between logical blocks and
CHS values so you dont get any head movement with
a bad thats been there all along, since the bad block scan,
when doing a linear read of the logical blocks sequentially.

The speed variation from track to track was less than 1%.
On some, but not all, drives I could see the delay for head
switching between cylinders, but there were 19, 38, or even
76 tracks in a cylinder, rather than 2, 4, or 8 and the in drive
buffers were much smaller, so normal track switches and
cylinder switches might not be vi sable now.

Certainly wont be when there is a modern
OS between the ute and the physical drive.

To see that sort of thing you need to read directly
from the drive with no OS getting in the road.

If anything, I would expect the drive to figure out that
I was reading sequentially and hide variations more

How ?

so that I would only see delays for soft
errors, but instead I see a 20% variation.

Thats the effect of the modern OS buggering up the timing.

That all begs the question tho, what's the point in this sort of
'analysis' when the OS is always having that effect on read timing ?

 

[Folkert Rienstra]

That last is very difficult to do at the Win level.

Easier done at the dos level.

And doesn't appear to work well with SCSI.

And has some real problems in some situations. There
is often only the roughest similarity with what HDTach
reports and HDTach appears to get it right better.

Showing the zones.

What is more than 20%? Are you referring to the 'grass'?

With the very big drives of today I have been thinking that
the number of blocks that is read per measurement point
(e.g. HD Tach reads 1MB chuncks) has been falling within a
cylinder, causing some points to have say 1 cylinder switch
included against zero on others, causing the uneven measure-
ment results within a zone.

Its basically due to the OS making it hard for anything
to show the read speed accurately because of what
else is going on.

Thats what produces the variation.

Hogwash! That grass wasn't there on smaller drives.

That approach isnt used anymore.


And that is only seen with sectors that have gone bad over time.

The modern approach is to allow for the bads in the
mathematical conversion between logical blocks and
CHS values so you dont get any head movement with
a bad thats been there all along, since the bad block scan,
when doing a linear read of the logical blocks sequentially.

That has never been different as to 'from factory state'.
A bad block was replaced by it's neighbour and the rest
pushed down the cylinder where the last block in the
cylinder is 'pushed' into the (cylinder) spare area.
Same goes for spares at the end.

The only difference *now* is that formerly the bad block's
ID-field pointed to where the replacement block was where
now the blocks are directly addressed through physical ge-
ometry info from ROM: Zone/Cylinder/Head/Sector.

Within a zone.

Presumably you mean 'notch' or 'zone', don't you?
No drive has 76 heads unless we are talking drums here.

 

[Rod Speed]

And doesn't appear to work well with SCSI.


Showing the zones.


What is more than 20%? Are you referring to the 'grass'?


With the very big drives of today I have been thinking that
the number of blocks that is read per measurement point
(e.g. HD Tach reads 1MB chuncks) has been falling within a
cylinder, causing some points to have say 1 cylinder switch
included against zero on others, causing the uneven measure-
ment results within a zone.

Doesnt explain that 20%

Hogwash!

Clueless. As always.

That grass wasn't there on smaller drives.

Even someone as stupid as you should be able to work that one out.

That has never been different as to 'from factory state'.

Wrong. As always.

A bad block was replaced by it's neighbour and
the rest pushed down the cylinder where the last
block in the cylinder is 'pushed' into the (cylinder)
spare area. Same goes for spares at the end.

Cant even manage a consistent line in pig ignorant bullshit.

The only difference *now* is that formerly the bad block's
ID-field pointed to where the replacement block was where
now the blocks are directly addressed through physical
geometry info from ROM: Zone/Cylinder/Head/Sector.

Completely clueless. As always.