Disk read speed benchmark wanted

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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.


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Mark Fineman <mark.s.fineman@verizon.net> wrote in
message news:ic8m60h8vo40sb9qaeb9hojdhikvgahc4i@4ax.com...

> 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 ?

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Rod Speed" <rod_speed@yahoo.com> wrote in message news:c4fcu4$2i8107$1@ID-69072.news.uni-berlin.de
> Mark Fineman <mark.s.fineman@verizon.net> wrote in message news:ic8m60h8vo40sb9qaeb9hojdhikvgahc4i@4ax.com...
>
> > 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 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.
>
> > It is accurate enough so that I can see when the
> > number of sectors per track changes (by looking
> > at the local peaks),

Showing the zones.

> > but the range in speed is more than 20%.

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

> > 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.

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.

>
> > 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.

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.

>
> > The speed variation from track to track was less than 1%.

Within a zone.

> > 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,

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

> > rather than 2, 4, or 8 and the in drive buffers
> > were much smaller, so normal track switches and
> > cylinder switches might not be visable 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 ?

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:c4fr5s$2hq78k$1@ID-79662.news.uni-berlin.de...
> "Rod Speed" <rod_speed@yahoo.com> wrote in message news:c4fcu4$2i8107$1@ID-69072.news.uni-berlin.de
> > Mark Fineman <mark.s.fineman@verizon.net> wrote in message news:ic8m60h8vo40sb9qaeb9hojdhikvgahc4i@4ax.com...
> >
> > > 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 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.
> >
> > > It is accurate enough so that I can see when the
> > > number of sectors per track changes (by looking
> > > at the local peaks),
>
> Showing the zones.
>
> > > but the range in speed is more than 20%.
>
> What is more than 20%? Are you referring to the 'grass'?
>
> > > 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.
>
> 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%

> > 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!

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.

> > > 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.

> 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.

> > > The speed variation from track to track was less than 1%.
>
> Within a zone.
>
> > > 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,

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

> > > rather than 2, 4, or 8 and the in drive buffers
> > > were much smaller, so normal track switches and
> > > cylinder switches might not be visable 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 ?