Western Digital Scorpio Black 500GB 7200 rpm. Model# WD5000BPKT Slow?

[Grumpy]

I have a friend who has built a 'mini' desktop with a Western Digital
Scorpio Black 500GB 7200 rpm. Model# WD5000BPKT hard drive.
He has unusual slow speeds when he copies folders and files from USB
flash drives to it.
Since this is a new system and a new drive, is there something special
he needs to do (format, initialize, etc) first?
He is running Windows 7.

Thanks

Grumpy

 

[Paul]

I have a friend who has built a 'mini' desktop with a Western Digital
Scorpio Black 500GB 7200 rpm. Model# WD5000BPKT hard drive.
He has unusual slow speeds when he copies folders and files from USB
flash drives to it.
Since this is a new system and a new drive, is there something special
he needs to do (format, initialize, etc) first?
He is running Windows 7.

Thanks

Grumpy

You can start, by using the free version of HDTune.
Do a benchmark run, and measure sustained transfer rate from end to end.
Also, using the SMART tab, check for problems there.

http://www.hdtune.com/files/hdtune_255.exe

Some examples of HDTune results, can be seen here. The outer diameter of
the platter can do about 134MB/sec, while in near the hub the drive
can do 67MB/sec. In these pictures, I was testing the impact of
jumpering my drive to SATA I or SATA II cable rates. If you see
references to "UDMA5" or "UDMA6", there's no such thing in SATA,
and SATA will always transfer at the controller, as fast as the
DMA on the system bus can manage (which is typically faster than
the disk platter can go anyway). So don't get "stuck" on any
UDMA settings. If the plot only goes to 7MB/sec and the plot
is a flat line, then that's equivalent to "PIO mode".

http://img829.imageshack.us/img829/842/500gb3500418ascomposite.gif

You'll see my curve in the upper left, has a "downward spike". If
you're seeing a lot of "downward spikes", those could represent
hard to read sectors, or sectors which have already been substituted.
Sometimes those spikes aren't "real", and testing later may find
a different, or no spike pattern. It's only if you find other
matching (application level) symptoms, you might conclude it is for
real. Or the SMART statistics may also reflect a problem with the
platter/heads etc.

If you pass that test, you can look at "alignment". The industry
is slowly moving to having all disks with 4KB sectors. Older
drives had 512 byte sectors. The 4KB drives also have "512e"
or 512 byte emulation, to help support older OSes. The emulation
succeeds in making a "backward compatible" disk, only performance
suffers if clusters aren't aligned to 4KB boundaries.

If you erased all partitions on the disk in Disk Management,
and used WinXP to make new partitions, they'll be aligned to
multiples of 63 sectors. This is not good for 4KB disks, but
some of the older partition management tools like it that way.
For example, my copy of Partition Magic (ancient), will throw
its hands in the air, if it finds disks without the magic 63 sector
multiples in the math.

Windows 7, aligns on 1MB boundaries. This smashes the magic 63
value. Such an alignment, keeps SSD drives with 64K, 128KB or
larger flash block sizes happy, keeps the 4KB disks relatively happy.
But may make some of your older tools (your Partition Magic)
unhappy.

So in terms of potential tools, Windows 7 is the perfect
tool by itself. Just go into Disk Management (Start : diskmgmt.msc
and right-click, "Run as Administrator" perhaps), erase the existing
partition, put a single new partition. Then, do some copy tests and see
if it is OK.

You can use this to review the existing partition table, as it
stands right now. Take a screen snapshot, and if any questions
come up in the future, as to "how was it partitioned originally",
you can refer to this result. PTEDIT32 must be "Run as Administrator"
in Windows 7, or you'll get an "error 5". If the disk alignment is
already on 1MB boundaries, then PTEDIT32 will likely error out.
It should also have a fixation about the number 63.

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip

This is an example of an old disk setup. The numbers on the right
of this display, are all likely divisible by 63. The CHS uses an
H of 254 (heads on the disk arm, which is ridiculous), and a sectors
per track count of 63 (which on modern high density drives, is also
silly). But these are the values used by large disks which are
actually running in LBA mode (similar to how SCSI disks work), and
the CHS isn't really meaningful any more. But when older OSes
plan partition sizes, they align to the bogus CHS parameters.

http://www.goodells.net/dellrestore/files/dell-tbl.gif

In my experience with what I suspect is a 512e drive, I found
that using "dd" program (disk dump, sequential transfer program),
the 512e drive works best with small block sizes like 4096 or 8192.
Older drives, true 512 byte sector drives, work best with as large
a transfer size as the drive will accept. Perhaps as many as
256 sectors or so. The newer drives, just don't seem to like that,
and I don't know exactly why. When you properly adjust the block
size while transferring, it can make a factor of three difference,
which is why I needed this information. (Imaging a disk might
run at 39MB/sec versus 13MB/sec, using the right transfer size
for the job. This is sector-by-sector disk copying, suitable
for copying badly damaged disks.)

On my 512e drive, another strange effect I was seeing, is the
"end of the disk" gave very choppy performance. This stopped
(for some reason), after running a read-verify from end to end
on the disk. That can be done with CHKDSK with the right
options enabled, or HDTune (rightmost tab) can also do a
read check (uses colored blocks to indicate if there are
errors, but I've never seen an error logged). Just the act
of reading every sector, from end to end, made the disk
behave better in subsequent days. And I don't know exactly
why that helped. It implies my disk was never read-verified
from end to end, at the Seagate factory.

Paul

 

[Grumpy]

You can start, by using the free version of HDTune.
Do a benchmark run, and measure sustained transfer rate from end to end.
Also, using the SMART tab, check for problems there.

http://www.hdtune.com/files/hdtune_255.exe

Some examples of HDTune results, can be seen here. The outer diameter of
the platter can do about 134MB/sec, while in near the hub the drive
can do 67MB/sec. In these pictures, I was testing the impact of
jumpering my drive to SATA I or SATA II cable rates. If you see
references to "UDMA5" or "UDMA6", there's no such thing in SATA,
and SATA will always transfer at the controller, as fast as the
DMA on the system bus can manage (which is typically faster than
the disk platter can go anyway). So don't get "stuck" on any
UDMA settings. If the plot only goes to 7MB/sec and the plot
is a flat line, then that's equivalent to "PIO mode".

http://img829.imageshack.us/img829/842/500gb3500418ascomposite.gif

You'll see my curve in the upper left, has a "downward spike". If
you're seeing a lot of "downward spikes", those could represent
hard to read sectors, or sectors which have already been substituted.
Sometimes those spikes aren't "real", and testing later may find
a different, or no spike pattern. It's only if you find other
matching (application level) symptoms, you might conclude it is for
real. Or the SMART statistics may also reflect a problem with the
platter/heads etc.

If you pass that test, you can look at "alignment". The industry
is slowly moving to having all disks with 4KB sectors. Older
drives had 512 byte sectors. The 4KB drives also have "512e"
or 512 byte emulation, to help support older OSes. The emulation
succeeds in making a "backward compatible" disk, only performance
suffers if clusters aren't aligned to 4KB boundaries.

If you erased all partitions on the disk in Disk Management,
and used WinXP to make new partitions, they'll be aligned to
multiples of 63 sectors. This is not good for 4KB disks, but
some of the older partition management tools like it that way.
For example, my copy of Partition Magic (ancient), will throw
its hands in the air, if it finds disks without the magic 63 sector
multiples in the math.

Windows 7, aligns on 1MB boundaries. This smashes the magic 63
value. Such an alignment, keeps SSD drives with 64K, 128KB or
larger flash block sizes happy, keeps the 4KB disks relatively happy.
But may make some of your older tools (your Partition Magic)
unhappy.

So in terms of potential tools, Windows 7 is the perfect
tool by itself. Just go into Disk Management (Start : diskmgmt.msc
and right-click, "Run as Administrator" perhaps), erase the existing
partition, put a single new partition. Then, do some copy tests and see
if it is OK.

You can use this to review the existing partition table, as it
stands right now. Take a screen snapshot, and if any questions
come up in the future, as to "how was it partitioned originally",
you can refer to this result. PTEDIT32 must be "Run as Administrator"
in Windows 7, or you'll get an "error 5". If the disk alignment is
already on 1MB boundaries, then PTEDIT32 will likely error out.
It should also have a fixation about the number 63.

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip

This is an example of an old disk setup. The numbers on the right
of this display, are all likely divisible by 63. The CHS uses an
H of 254 (heads on the disk arm, which is ridiculous), and a sectors
per track count of 63 (which on modern high density drives, is also
silly). But these are the values used by large disks which are
actually running in LBA mode (similar to how SCSI disks work), and
the CHS isn't really meaningful any more. But when older OSes
plan partition sizes, they align to the bogus CHS parameters.

http://www.goodells.net/dellrestore/files/dell-tbl.gif

In my experience with what I suspect is a 512e drive, I found
that using "dd" program (disk dump, sequential transfer program),
the 512e drive works best with small block sizes like 4096 or 8192.
Older drives, true 512 byte sector drives, work best with as large
a transfer size as the drive will accept. Perhaps as many as
256 sectors or so. The newer drives, just don't seem to like that,
and I don't know exactly why. When you properly adjust the block
size while transferring, it can make a factor of three difference,
which is why I needed this information. (Imaging a disk might
run at 39MB/sec versus 13MB/sec, using the right transfer size
for the job. This is sector-by-sector disk copying, suitable
for copying badly damaged disks.)

On my 512e drive, another strange effect I was seeing, is the
"end of the disk" gave very choppy performance. This stopped
(for some reason), after running a read-verify from end to end
on the disk. That can be done with CHKDSK with the right
options enabled, or HDTune (rightmost tab) can also do a
read check (uses colored blocks to indicate if there are
errors, but I've never seen an error logged). Just the act
of reading every sector, from end to end, made the disk
behave better in subsequent days. And I don't know exactly
why that helped. It implies my disk was never read-verified
from end to end, at the Seagate factory.

Paul

This is actually what my friend said on this:

This new computer seem so slow compared to my old Intel system. Last
night I downloaded about 7 GB of music files off my old computer to a
thumb drive file by file, It took less than 30 minutes. Today I'm
trying to load those files to the new computer and it says it will
take 3 hours to load them. I believe it since it's already been one
hour and it's showing 2 hours remaining. Now my old computer is 3.06
dual core processor running XP 32 bit, while the new one is only 1.6
dual core, but it's running Win 7 ULT 64 bit. I would expect some
loss of speed, but not this much! Any ideas as to what may be causing
this? It runs video and such great, but taking this long to just copy
files from one a thumb drive to the HD doesn't seem right.

Thanks for your detailed advice. You're always there! I have talked
with you before.

Grumpy

 

[Paul]

This is actually what my friend said on this:

This new computer seem so slow compared to my old Intel system. Last
night I downloaded about 7 GB of music files off my old computer to a
thumb drive file by file, It took less than 30 minutes. Today I'm
trying to load those files to the new computer and it says it will
take 3 hours to load them. I believe it since it's already been one
hour and it's showing 2 hours remaining. Now my old computer is 3.06
dual core processor running XP 32 bit, while the new one is only 1.6
dual core, but it's running Win 7 ULT 64 bit. I would expect some
loss of speed, but not this much! Any ideas as to what may be causing
this? It runs video and such great, but taking this long to just copy
files from one a thumb drive to the HD doesn't seem right.

Thanks for your detailed advice. You're always there! I have talked
with you before.

Grumpy

A copy operation has a source device and a destination device, and both can
be tested for performance. With luck, HDTune will test both. HDTune
testing a half-ways decent USB key, will get approximately 30MB/sec
when benchmarked, and the graph will be a flat line. All of the flash
runs at the same speed, so there is no "tilt" to the curve. USB flash
has a seek time of around 1 millisecond, and that small amount of time
is due to the USB protocol, rather than being the flash itself.

I have what's referred to as a "dual channel" USB key, one with
a controller chip and two flash chips, and it reads at 30MB/sec
and writes at 18MB/sec. So read and write are not symmetric, and
read seems to work better (because there's no erase step required
there). On a USB key with one flash chip, and one flash channel,
you might no longer be USB2 bus limited (read and write might
be in the 9-10MB/sec range). So if HDTune gives values like 9MB/sec,
that's typical for a single channel key on USB2 bus. The very
best USB keys now run on USB3 (and are physically quite large),
and they do significantly better. Not "SSD good", but still
pretty impressive.

Windows 7 copies and buffers in slightly different ways than WinXP.
The initial version of Vista, was doing a poor job of this, having
been a rewrite from scratch for no good reason (they didn't just
reuse old code). Later attempts, improved on that (but it's still
prefaced on asynchronism, so that you can be doing other things while
the transfer is happening). You'd have to look for some articles by Mark
Russinovich, to find out what changed and so on.

http://blogs.technet.com/b/markrussinovich/archive/2008/02/04/2826167.aspx

*******

The two quoted figures from your friend, work out to 4MB/sec on the first
transfer, and 0.7MB/sec predicted on the second transfer. The 0.7MB/sec rate is
so poor, it's "sub USB1.1" rate. If the hardware lacked a USB2
driver on Windows 7, you saw a warning "this hardware could operate
faster in USB2 mode" or whatever, that would be telling you it
was running in USB 1.1 mode. While the theoretical wire rate
is 12Mbit/sec (1.5MB/sec), actual transfer rate is 1.0MB/sec or
a bit less for USB 1.1. I find the 0.7MB/sec estimate to be bad enough,
maybe something else is making it even slower.

At that speed, even if average file size was 4KB, you'd still be
able to thrash the hard drive faster than the predicted rate.
So I don't think this is a "hard drive head seek" type limit.
A modern hard drive can do 2-3MB/sec under pessimistic conditions
(mostly seek head movement, very little actual data writing). So
at 0.7MB/sec, it should not be the fault of the hard drive. Even
if the hard drive was in PIO mode, PIO transfer with a modern
processor works at around 7MB/sec, so it still couldn't be slowed
to that extent. You'd have to be "USB 1.1" on the source end,
as well as some other bottleneck being present (maybe, bad blocks
being detected or something, and the disk pausing or stuttering).

Whatever the problem is, it sounds pretty pathetic.

I doubt this is a hardware problem, and my suggestion of
testing with HDTune, is intended to be a relatively "low labor"
test case. It won't answer all the questions, but will be a good
start to proving it isn't a plumbing problem. If it's actually
something about the copying code in Windows 7, it could be a good
deal harder to trace down. (The Russinovich article shows how
he studies such things.)

When I want to double check hardware, I sometimes boot a Linux
LiveCD and repeat the test case there, and see if the same
performance or issues show up. But preparing a LiveCD is a lot
more work and time, than a few minutes with HDTune.

File transferring, doesn't normally take a lot of CPU. That's
because of "DMA transfer" for the data. And even with PIO, if
you were stuck in a PIO mode, the CPU usage could increase,
but you'd also be getting 7MB/sec on the PIO limited device
(ten times the predicted transfer rate). If your friend opens
Task Manager (ctrl-alt-delete), and looks at the graph,
I'm willing to bet the CPU usage is in the 10% range. But
your friend can check that.

Even a 300MHz Celeron, should be able to transfer files
at a decent speed (that's assuming it isn't running all
the background tasks in Windows 7 of course). Just the file
transfer portion, should not be that taxing.

If the Windows 7 indexer was running, that could slow things
down. But the indexer is disabled by default, and it was
several months before I figured it was worth turning on.
Some AV software can "scan" every file that is being read
from a storage device, and that can have a significant
effect. Some people, being overly clever, even manage
to install *two* real time AV products, and when you
copy files, the file is being read *three* times. So
if a user "uses a big enough hammer", yes, the computer
will seem broken

Paul

 

[Grumpy]

Hey Paul -

My friend wants to know if the drivers on my Windows 7 installation
are 32-bit or 64? Not sure how to tell. He is thinking that may be
his problem. Anyway I see on my machine:

disk.sys
partmgr.sys
snapman.sys
tdrpm2735.sys

device manager shows the above under windows\system32\drivers for my
hard drive. Don't know what his says.

Does this tell you anything? Maybe I am not looking right?

Thanks

Grumpy

 

[Paul]

Hey Paul -

My friend wants to know if the drivers on my Windows 7 installation
are 32-bit or 64? Not sure how to tell. He is thinking that may be
his problem. Anyway I see on my machine:

disk.sys
partmgr.sys
snapman.sys
tdrpm2735.sys

device manager shows the above under windows\system32\drivers for my
hard drive. Don't know what his says.

Does this tell you anything? Maybe I am not looking right?

Thanks

Grumpy

The bullet near the bottom of these pages, says 64 bit drivers go with
the 64 bit OS. I don't know if that is absolutely true or not. It's
just what Microsoft is claiming.

http://windows.microsoft.com/en-US/...and-64-bit-Windows-frequently-asked-questions

http://windows.microsoft.com/en-US/windows7/32-bit-and-64-bit-Windows-frequently-asked-questions

*******

Windows 7 has two Program Files folders, with the intention of
sorting programs as 32 bit or 64 bit.

I don't know if the drivers have a parallel kind of structure.
As near as I can remember, there's only one structure for them.

*******

I use a program called "file" (gnuwin32), and it can tell the
difference between 32 bit and 64 bit code. I presume there is
a bit in the header, that marks 64 bit code. The "file" program
says 32 bit programs are "PE32" while 64 bit programs are "PE32+".
The "file" program also recognizes .NET programs, but I'm not
convinced it is doing a 100% accurate job on them.

http://en.wikipedia.org/wiki/Portable_Executable

The "file" program started life on Unix boxes. It uses a file
called "/etc/magic", and to identify a file, people figure out
the minimal amount of a file that needs to be "sniffed", to figure
out its type. The /etc/magic file contains a list of recipes, in
a particular kind of scripting language, to help the main program
identify files.

An objective, is to only read a 1KB or less chunk of the file,
so that a lot of I/O isn't needed. Some files are dead easy, as
you can figure them out in four or eight bytes (years ago,
Microsoft Office files might have been that easy).

But I think some of the files now, need quite a few sniffs to
get them dead right.

If I run the "file" program, looking for text files, it returns
about 130 different responses (so it can tell you where a text
file may have come from, or what line endings the file has).
That is both a plus and a minus for the program, when you're
looking for a more focused result. Some people would find
such a result, a little too verbose.

The package can be found here. A nuisance factor of this particular
package, is the magic file cannot be placed loose next to the
file.exe program and work. It is folder relative, meaning
file.exe goes "cd .." and then I think it looks in the lib
folder for the magic file. It makes it more of a PITA to install
the way I install them. If the automated installer actually works,
you won't have to worry about that.

http://gnuwin32.sourceforge.net/packages.html

"File 5.03 determine file type"

Those packages are ports, intended to run under Windows. I
usually install the programs manually. I haven't tried their
automatic installer for a while, so I can't tell you whether
they properly modify the "path" variable so Windows can find
the program when you want to run it. I usually dump the
file, any DLLs, into a folder where I want to work, and
in Command Prompt, "cd" to the directory with the executable
and run it from there.

For example, to test the program on itself, I would run

file file.exe

and it would tell me "PE32 executable" or the like. If
I said

file <path_to_driver_file\driver.dll>

I presume it could tell you whether the file was PE32 or PE32+.

*******

Microsoft does have programs for identifying file type,
but nobody at Microsoft apparently understands what customers
want. For example, there is a program that examines some
header bits in .NET files, but then the program doesn't
handle anything other than that. So when MS writes utilities
of that nature, they don't "think big" while doing it. I
wouldn't be toying with that bloody "file" program, if
I could possibly avoid it. But when nobody else will
solve the problem, it's a step in the right direction.
So when I need a tool that can tell me something about
a file, I resort to "file.exe", for better or worse.

Going by the file extension alone in this case, just
isn't enough. And that's why file.exe looks inside the file.

You might wonder, why I would be scanning a directory for
text files. I downloaded the source tarball for Firefox.
All the text files have Unix line endings, which means
I have to open the files in Wordpad to read them. There
are programs called "unix2dos" and "dos2unix", that
can convert the line ending, so I can read the files
in Notepad instead. So, using the "file.exe" program,
and a script, I asked "file.exe" to point out all
the Unix text files. Then, once I had all the file
names in a list, I ran "unix2dos blah.txt" on each one, to
make them all Notepad compatible. It allowed me to
double-click on any source file in my Firefox source
directory, to read them. Firefox has something like
1.2 million lines of code, and it's almost impossible
to make any sense out of it And the last thing
I wanted, was to be doing "Open" from the Wordpad menu
to read each file. I just wanted to click on them.

Paul

 

[Grumpy]

Google "windows 7 slow file copy." This was a widely occurring problem
with vista and persisted on some installations of 7 so it _may_ be what's
going on. Unfortunately, I forget the fix but it was fairly easy.

Good luck.
Mike

WOW!

Thanks

Grumpy

 

[Anssi Saari]

This new computer seem so slow compared to my old Intel system. Last
night I downloaded about 7 GB of music files off my old computer to a
thumb drive file by file, It took less than 30 minutes. Today I'm
trying to load those files to the new computer and it says it will
take 3 hours to load them. I believe it since it's already been one
hour and it's showing 2 hours remaining. Now my old computer is 3.06
dual core processor running XP 32 bit, while the new one is only 1.6
dual core, but it's running Win 7 ULT 64 bit.

I wonder what this computer is really? 1.6 GHz dual core? Sounds like
maybe Atom D510 from Intel? Maybe with some exotic USB hardware that
needs drivers installed for USB2 since that seems like a likely reason
for the slow speed?

 

[John McGaw]

I have a friend who has built a 'mini' desktop with a Western Digital
Scorpio Black 500GB 7200 rpm. Model# WD5000BPKT hard drive.
He has unusual slow speeds when he copies folders and files from USB
flash drives to it.
Since this is a new system and a new drive, is there something special
he needs to do (format, initialize, etc) first?
He is running Windows 7.

Thanks

Grumpy

Does the USB thumb drive in question have a rated read and write speed? Is
it achieving what is it supposed to? What does the USB drive behave like
(both read and write) when plugged into another known-good computer? What
do read and write speed tests of the hard drive show?

At that, why use a USB thumb drive for data-intensive work at all? Hasn't
your friend heard about this newfangled thing called a network?