Went from Fujitsu 80gb 5.4k HD to WD3200BEVT 5.4k and all is good but Burst and CPU useage

I made 3 runs on the WD3200BEVT and the results are consistent and not a mere anomoly.

I just went from an 80gb Fujitsu MHW2080BH to a 320gb Western Digital WD3200BEVT and while the OS install and everything like that went faster, HD tune is saying my Min, Max and Average speeds along with my random access are faster while my burst rate is down and my cpu useage doubled.

I didn't bench the WD3200BEVT untill I installed all of the exact same software and performed all of the same updates and I made sure all other settings were identical.

This is on a Sata150 bus so this may explain the lower than normal WD3200BEVT speeds I have.

Here is what I'm talking about, let me know if this seems odd to anyone else:

MHW2080BH


WD3200BEVT


Run 2


Run 3

 

Doesn't look like anything to worry about. 3mb difference in burst rate is too small a difference to show a reduction performance. Besides if you run the benchmark again you might find it faster by 3mb or more.

As far as CPU usage is concerned perhaps your CPU was doing something else in the backround. Perhaps disable all backround tasks then run it again.

 

I ran it in the same manner as before though so even with the unit disconnected from the net and wifi disabled and still cpu useage is doubled. I'll rerun the benchmark but I found that run to be very odd, I'll repost when I rerun but will take a couple minutes. I may be jumping the gun here.

 

As for your burst rate, I wouldn't worry about it as it's the theoretical max transfer rate.

 

Well, it's consistent in the CPU useage and lower burst rate. I don't see how a drive this many generations newer could perform worse in anything. Any ideas? Firmware update or install the intel storage driver?

 

You could give the ISD a try. The HDD experts on here do recommend it although I haven't got around to trying it yet.

Either way don't worry yourself over synthethic benchmarks. If your system loads faster and feels faster than before then those tangible differences are what matter.

 

But shouldn't CPU usage be higher during the benchmark if the drive is drastically faster? That is a lot more data that it has to process.

 

Did you update your chipset driver? And not counting your laptop manufacturer's drivers, those are usually ancient. Update your chipset drivers.

 

Good point Trottel! Didn't think of that

 

HDTune and burst rates and cpu usage should be taken with a grain of salt. SSD's can 'score' at -1% CPU usage for example.

What you want to see is better results in a program that has no relationship to the real world usage you'll put your drive through. I suggest to stop chasing that particular 'wild' goose.

To ensure that you are testing in a similar environment though, try this if you're running Windows Vista or Windows 7:

Open up a command prompt with Adminstrator rights.

Paste the command below into the cmd window and hit enter.

Rundll32.exe advapi32.dll,ProcessIdleTasks

The hard drive and/or system may be busy for the next few minutes, be patient.

Paste the following into the cmd window and hit enter:

defrag c: -b

(Note, the above command will not work in XP).

When the HD light has stopped, I suggest running the first command again.

What the first command does is force all the tasks that are waiting to run when you're not using your computer to run now.

When the command has finished running (I run the 'defrag c: -b' command to check that the 'Rundll32.exe advapi32.dll,ProcessIdleTasks' command has finished.....), run your benchmarks again.

The above procedure will give you the most consistent basis for comparing between the two drives in a 'live' Windows install.

Alternately, you can reboot into 'Safe Mode' and run the benchmarks there - but to me, this does not accurately reflect the working conditions of how we normally use the drive(s) and consider the results under 'Safe Mode' useless. But, it will also let you test the drives in as similar conditions as possible, so its your call.

Good luck.