Home Consumer How To: Improve Low SSD Performance in Intel Series 5 Chipset Environments

How To: Improve Low SSD Performance in Intel Series 5 Chipset Environments

by Brian Beeler
Forums member StamatisX has created the following how to guide and analysis of what appears to be a commonly reported problem – SSDs are not reaching their full performance potential in many notebooks and some desktops using the Intel Series 5 chipset. While not a definitive study on the issue, StamatisX does provide a detailed look into the problem and provides tweak options that help alleviate the performance issue until the concern is addressed more soundly by the OEMs, Intel or both.


Editor’s Note: Forums member StamatisX has created the following how to guide and analysis of what appears to be a commonly reported problem – SSDs are not reaching their full performance potential in many notebooks and some desktops using the Intel Series 5 chipset. While not a definitive study on the issue, StamatisX does provide a detailed look into the problem and provides tweak options that help alleviate the performance issue until the concern is addressed more soundly by the OEMs, Intel or both. 
 
By StamatisX
 
Equipment list:
 
Dell Alienware M17x R1
Dell Alienware M17x R2
Intel X25-E 64GB SSD
 
On my R1 this SSD was giving me excellent benchmarking numbers and especially very fast access times (0.065ms read and 0.056ms write). When the time came to install this $750 drive to my R2 and started benching, I soon realized that something was wrong. I could not get the numbers I was seeing before on my R1; no matter how many tweaks I applied. I ended up secure erasing and formatting the disk again and again, trying to find out what driver combination and what Windows tweaks would give me the best results and performance close to my R1, unfortunately in vain.
 
I decided to open a thread on the official support forum of both Dell and Intel concerning this matter. Those threads have received no reply whatsoever from either Dell nor Intel representatives. I have even sent an email to a couple of Dell representatives explaining the situation with the promise that they would contact the engineers concerning this matter. I have not received any reply from them nor the engineers.
 
The Problem
 
First I will provide you with a couple of screenshots of benchmark runs from the R1.
 
 
 

Safe Mode
 
As you can see we get excellent results for both 4K random read and write, as well as remarkable read and write access times (even in safe mode, demonstrated on the third screenshot), that is with the default Microsoft drivers that come by default with Windows 7 and the Nvidia chipset drivers from Dell.
 
Now let us take a look on two similar screenshots, this time from the R2..
 
 
 
 
The first is with the default MS drivers and the rest are with the latest chipset and storage drivers from Dell and Intel respectively. Very low 4k random read and write numbers and the same for the read and write access times. I got very similar numbers with every driver that I have tried.
 
Now let’s take a look at Crystal Disk Mark numbers.
 
 
 
The second screenshot of CDM was in Safe mode. Those numbers made me suspicious about the power saving features. I did some research on the web and I found out that desktop users were experiencing low performance as well, but were able to increase those numbers by simply disabling the EIST and the CPU C states from the BIOS. 
 
This issue is widespread – members from the NotebookReview.com forum have observed the very same behavior with systems like HP, Lenovo, Asus, Dell and others, all of which have the PM55/HM55 chipset. 
 
Some Asus owners found out that their SSD performance was increased while running a CPU intensive program in the background during benchmarks. That gave me the idea of tweaking the registry of Windows a little in order to achieve better results that you will see later on in this article.
 
But how do those low random 4K read/ write numbers and access times affect the real world performance? I decided to perform a couple of tests that demonstrate the difference we already have noticed on those synthetic benchmarks.
 
Testing Methodology
 
I ran a set of tests, 3 times each, using 3 different registry settings on 3 clean Windows installations where the drive was first secure erased and then making sure it was aligned and formatted with the default 4K cluster size. The results you see here are from my last try since the other two gave almost identical results. The only drivers installed were the chipset drivers (version 9.1.1.1015) and storage drivers both from Dell’s website (RST 9.6.0.1.1014). No other drivers or updates were installed, not until I had to install the MSE and the wifi drivers (from Dell’s website) in order to download the latest virus definitions, otherwise it wouldn’t let me scan the disk. The power plan applied for all the tests was the high performance one.
 
First I copied 5 files from my internal 7.2K 320GB Seagate to the desktop (Windows is installed on the SSD). Those times were the same, and remained the same for all the different settings that I tried.
 
File Name
File Type
File Size in MB
Time to Copy in seconds
Ubuntu 9.10 Desktop i386
.iso
689
11
Back Track 4
.iso
1,460
20
MS Office 2010 Professional Plus
.exe
643
10
Video clip
.mov
1,091
15
Visual Studio 2010 Ultimate
.iso
2,270
34
 
Those file transfers are mostly depended on sequential reads and writes which are not affected by the various drivers I tried or the CPU load and the difference between runs was the most ±1sec and that was because of my accuracy with the stop watch throughout those tests. According to those results we can safely assume that the copy and paste of large files between different disks and between folders on the same disk is definitely not affected.
 
The next test was to measure the time it takes for a relatively big program to install. For this purpose I found MS Office 2010 Professional Plus in the form of a single executable file (643MB in size) that I copied to my desktop and installed in full. I broke the measuring times down to how long it takes for the file to extract itself, how long it takes to install all of the programs and features and how long it takes to completely uninstall.
 
Using the default Windows settings, average, it took:
 
Time to Extract (in seconds)
Time to fully install (2.42GB in size)
Time to fully Uninstall (in seconds)
44
274
120
 
The next step was to install a bigger program like Visual Studio Ultimate 2010 that is more CPU intensive and in full installation occupied 7.7GB (without including the help files). Due to the fact that I wanted to utilize only my SSD, I found an ISO of the program and used daemon tools lite to mount the ISO to a virtual drive and install it from my SSD to the SSD. The time it took to install all of its features was:
 
Time to Install in full (in seconds) (7.7 GB disk space)
Time to Uninstall (in seconds) (only the Visual Studio 2010 Ultimate-ENU)
994
214
 
(The rest of the components had to be uninstalled manually from the control panel and they were too many to measure the time accurately for each of them)
 
Another test was to measure how fast Microsoft Security Essentials could scan all the items under the C drive. On average there were:
 
Items
Time for scan to complete (in seconds)
11,819
309
 
The last test for the default settings was SuperPI that completed the calculation of 1M digits in 12 seconds average, which is irrelevant to the SSD but the reason I used it will be clearer later on.
 
These were the idle temperatures of the CPU with the default Windows settings:
 
 
The next set of tests was performed by applying a registry tweak that prevents the CPU from idling.
In order to do that, open the registry, go to:
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00\5d76a2ca-e8c0-402f-a133-2158492d58ad]
 
and change the “Attributes” from 1 to 0. Then, change the advanced power settings like the screenshot below:
 
 
The installation of Microsoft Office Professional Plus 2010 took:
 
Time to Extract (in seconds)
Time to fully install (2.42GB in size)
Time to fully Uninstall (in seconds)
49
254
60
 
The Visual Studio Ultimate 2010 took:
 
Time to Install in full (in seconds) (7.7 GB disk space)
Time to Uninstall (in seconds) (only the Visual Studio 2010 Ultimate-ENU)
611
212
 
For MSE to perform a full scan of the C drive with 116,814 items it took 6 minutes and 52 seconds.
 
Items
Time for scan to complete (in seconds)
11,814
412
 
For SuperPI, the calculation of 1M digits took 17 seconds.
 
The idle CPU temperatures were:
 
 
The last set of tests was performed using a different registry tweak that disables the CPU drivers through Windows registry.
 
In order to do that, open the registry, go to:
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\intelppm]
 
and change "Start" from 3 to 4. Then go to:
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Processor]
 
and change "Start" from 3 to 4.
 
The installation of MS Office 2010 Plus 2010 took:
 
Time to Extract (in seconds)
Time to fully install (2.42GB in size)
Time to fully Uninstall (in seconds)
43
237
47
 
For VS 2010 Ultimate the times were:
 
Time to Install in full (in seconds) (7.7 GB disk space)
Time to Uninstall (in seconds) (only the Visual Studio 2010 Ultimate-ENU)
446
148
 
MSE scanned:
 
Items
Time for scan to complete (in seconds)
11,819
295
 
SuperPI complete 1M digit calculations in 12 seconds
 
The idle temperatures were:
 
 
Now it’s time for the synthetic benchmarks.
 
For the default Windows settings we have:
 
 
 
 
 
 
 
IOMETER
4K random reads
 
Read IOps
3,234.909258
Read MBps
12.636364
Average Read Response Time
0.308033
Maximum Response Time
1.381969
% CPU Utilization
2.43567
 
4K random writes
 
Write IOps
6,179.623475
Write MBps
24.139154
Average Write Response Time
0.160776
Maximum Write Response Time
94.758776
% CPU Utilization
4.431797
 
The results with the registry tweak to prevent the CPU from Idling:
 
 
 
 
 
 
 
4K random reads
 
Read IOps
5,816.876566
Read MBps
22.722174
Average Read Response Time
0.171542
Maximum Response Time
1.275049
% CPU Utilization
1.599719
 
4K random writes
 
Write IOps
13,331.33272
Write MBps
52.075518
Average Write Response Time
0.07464
Maximum Write Response Time
95.619893
% CPU Utilization
4.855217
 
Disabling the CPU drivers gives us the following results:
 
 
 
 
 
 
 
4K random reads
 
Read IOps
5,218.73
Read MBps
20.38566
Average Read Response Time
0.190913
Maximum Response Time
1.277938
% CPU Utilization
2.609417
 
4K random writes
 
Write IOps
11,102.85
Write MBps
43.37049
Average Write Response Time
0.089388
Maximum Write Response Time
95.577145
% CPU Utilization
6.109794
 
 
What Does it All Mean?
 
With the default settings we get very low 4K random reads and writes, low access times but the temperatures remain low as well, CPU performance is not affected either. With the basic registry tweak that prevents the CPU from Idling we get very good results on our synthetic benchmarks but the idle temperatures are unacceptable and affect negatively the real world performance(mostly because of the CPU not because of the SSD).
 
The registry tweak that disables the CPU drivers gives better synthetic results compared to the default settings but lower than those that prevent the CPU from idling. Instead we get lower temperatures and the best real world performance out of those three.
 
The tweak that prevents the CPU from idling can be further tuned for much better results concerning temperatures (and real world performance) but you need to try too many combinations and those results will vary according to the CPU (it has to be fine-tuned by the user). 
 
For those who want to improve their SSD with the minimum amount of registry changes, all they have to do is to disable the CPU drivers by editing two values on the registry. As a warning though, none of those tweaks were extensively tested over the long-term and their side effects remain unknown so apply them on your own responsibility and always with caution. Always remember to take a backup of your data before you decide to change anything in your system.
 
Also keep in mind that those suggestions are not the final solution to the problem we described here. Those are simple patches until Intel or any other OEM decides to take a look at this issue and give their own suggestions and explanations.

Discuss This Story