Could Windows' 7 benchmarking be much slower because of RST drivers?

Important Drivers Specific: Intel AHCI/RAID Drivers
1

For the past couple years, my “Windows Experience Index” score for my hard drive (Intel 320 SSD 160GB) has been 7.7. However, I discovered just yesterday that it now shows 5.9.

I only discovered this by chance, as I never really check the WEI. So it’s possible that it’s been 5.9 for the past couple months, in which time I’ve upgraded my ICH10 controller drivers multiple times (having to manually edit the .INF files because ICH10 isn’t officially supported into the v12+ drivers).

Of course, I realize WEI isn’t a useful indicator of performance, however, I do worry that such a drop in score is perhaps somehow connected or related to the performance of my hard drive speeds/functionality, especially given my “forcing” of upgrades to v12’s.

1.) Is it possible to determine the source of why my WEI disk score has dropped so much, and perhaps fix it?

From what I’ve read, 5.9 is the highest score that can be given a non-SSD drive – however, looking at the details of the WEI, and also in the DataStore .xml file, it appears that my SSD is still being considered the primary drive, and not one of my other spindle-storage drives.

Oddly, however, the .xml file does appear to be missing a number of performance “metrics” that are found on prior tests:


Here’s my WEI test from yesterday. For the record, I’m using RST driver 12.8.0.1016 for my ICH10 controller (driver-only; no RST software installed):

1
2
3
4
5
6
7
8
9
10
 
<WinSPR>
   <DiskScore>5.9</DiskScore>
</WinSPR>
<Metrics>
   <DiskMetrics>
      <AvgThroughput kind="Sequential Read" units="MB/s" ioSize="65536" score="7.4">224.00000</AvgThroughput>
      <AvgThroughput kind="Random Read" units="MB/s" ioSize="16384" score="7.5">156.12000</AvgThroughput>
      <Responsiveness Kind="Cap" Reason="UnableToAssess">TRUE</Responsiveness>
   </DiskMetrics>
</Metrics>
 


For comparison, here's my WEI .xml from this past June 2013 (I can't remember which driver I was on):

1
2
3
4
5
6
7
8
9
10
 
<WinSPR>
   <DiskScore>7.7</DiskScore>
</WinSPR>
<Metrics>
   <DiskMetrics>
      <AvgThroughput kind="Sequential Read" units="MB/s" ioSize="65536" score="7.4">224.84250</AvgThroughput>
      <AvgThroughput kind="Random Read" units="MB/s" ioSize="16384" score="7.5">155.92000</AvgThroughput>
      <Responsiveness Kind="Cap" Reason="UnableToAssess">FALSE</Responsiveness>
   </DiskMetrics>
</Metrics>
 


Even though it appears WEI is only running two metrics in each test for some reason (I have no idea why) -- "Sequential Read" and "Random Read" -- the numbers across the two tests are almost exactly the same. What does differ, however, is the "Responsiveness:Cap - UnableToAssess" -- the June 7.7-scored WEI reports this as "FALSE", while the most recent WEI test yesterday reports this as "TRUE".

I don't know what to make of this or what that metric even means, or where to start digging to troubleshoot/investigate.

For the record, here is an old WEI .xml I have from March 2012. This was when I was still using either RST 10 or 11's, as well as having the full RST software package installed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<WinSPR>
   <DiskScore>7.7</DiskScore>
</WinSPR>
<Metrics>
   <DiskMetrics>
      <AvgThroughput kind="Sequential Read" units="MB/s" ioSize="65536" score="7.5">262.11000</AvgThroughput>
      <AvgThroughput kind="Random Read" units="MB/s" ioSize="16384" score="7.9">228.41000</AvgThroughput>
      <Responsiveness Kind="AverageIORate" units="ms/IO" score="7.9" factor="0.0">0.80000</Responsiveness>
      <Responsiveness Kind="GroupedIOs" units="units" score="7.3" factor="0.0">9.23625</Responsiveness>
      <Responsiveness Kind="LongIOs" units="units" score="7.9" factor="0.0">2.04744</Responsiveness>
      <Responsiveness Kind="Overall" units="units" score="7.8" factor="0.0">18.91064</Responsiveness>
      <Responsiveness Kind="Cap" Reason="PASSED">FALSE</Responsiveness>
   </DiskMetrics>
</Metrics>
 


I don't know why that test shows so many more "Responsiveness" metrics tested.

Again, I realize WEI isn't an effective measure of performance. But besides the bit of OCD I have in worrying about a dropped score :) , I'm more concerned that it's a secondary indicator that my drive is somehow not being utilized to its optimal best, possibly in lieu of "forcing" v12 drivers (or perhaps because I'm not using the RST software, as well...? Wouldn't seem like that would negatively affect anything...)

I've attached the three different WEI's if anyone cares to take a look.

2012-03-08 04.23.00.262 Disk.Assessment (Initial).WinSAT.xml (48.5 KB)

2013-06-25 17.19.53.192 Disk.Assessment (Recent).WinSAT.xml (38.5 KB)

2013-08-29 18.53.39.188 Disk.Assessment (Recent).WinSAT.xml (38.5 KB)

2

Here are my comments:

  1. As you already mentioned, the Windows Experience Index is not a valuable benchmark tool. Furthermore it may happen, that the WEI tool doesn’t correctly detect the SSD as SSD and shows a wrong score.
    To verify, if you really got a performance drop caused by anything unknown, you should run a real benchmark tool loke AS_SSD and compare it with previous results.
  2. The Intel v12 Series RST drivers were neither designed nor optimized for being used with an outdated OS like Windows 7 and an outdated 4-Series Chipset mainboard like yours.
    That is why I have never recommended to use any Intel RST(e) driver version from v11.5 up for a system like yours. For details you may look >here<.
  3. The RST Software has nothing to do with the performance of an SSD, which is running in AHCI mode.

3

I would think that newer drivers are almost always better, if nothing else but for the continual refining in bug fixes (which there seem to be in every subsequent revision) – Is this not the case (or worth doing so)?

And you mention 11.5 drivers above, but on the page you referenced, you propose 11.2 and 11.7. Why choose one over the other?

I can’t find whether my ICH10R controller is 4-series or 5-series. Is the controller what’s regarded as a “series”, or is it the chipset (or the whole thing)? I have an eVGA x58 758 motherboard (using an ICH10R SATA controller). I’ve put a custom BIOS on it, running an OROM of 12.7.0.1936.

For my setup, I run Windows 7 x64, using a single Intel 320 160GB SSD as my main drive (AHCI mode), and a handful of secondary platter drives for storage. I don’t use any kind of RAID. I like fast performance, but also like efficiencies and “bug” fixes. As you’ve suggested, my older set probably isn’t taking advantage of any of the new features – but is it able to take advantage of bug fixes?

Anyway, with all that being said – what do you recommend? 11.2/11.5/11.7?

And to drop down to one of these from 12.8, do I need to do anything “special”, or be particularly careful? I seem to remember you mentioning somewhere about the dangers of going “backwards” from the 12-series drivers down to the 11-series.

Thanks for the help.

4

Newer drivers should be better than older ones, but they are not always better for systems, which are not actual anymore.

What do you mean with your last sentence? Where have I recommended Intel RST v11.5 drivers?
The v11.2.0.1006 are the last and probably best "classical" Intel AHCI/RAID drivers, which do their work with 1 single driver named iaStor.sys. All Intel RST(e) drivers from v11.5.x.xxxx up are working totally different from the "classical" ones, because they use an additional SCSI filter driver named iaStorF.sys. Not all Intel SATA AHCI/RAID Controllers get benefit from this dual driver system.

The Intel ICH10R SATA Controllers belong to the 4-Series (llok >here<). The X58 chipset may have a 5-Series Northbridge, but definitevely a 4-Series Southbridge and only the latter is important for the choice of the suitable AHCI or RAID driver, because the SATA Controllers are part of the Southbridge.

The development of the "classical" Intel RST drivers ended with the v11.2.0.1006, that means, that all bugs of the Intel RST series, which started with v9.5.1037, have been fixed or couldn’t been fixed. In July 2011 Intel started the development of a completely new branch of their RST(e) AHCI/RAID drivers with a completely changed functionality and completely new bugs. The first version was 11.5.0.1109 Alpha and the latest version of the RST(e) series is v12.8.0.1016.

For systems with an Intel ICH7-10 SATA Controller I recommend to use v11.2.0.1006, the last and best of the classical Intel RST drivers. Nevertheless you may try any version of the Intel RST(e) series (e.g. v11.7.4.1001), but I do not recommend at all the use of any Intel AHCI/RAID drivers v11.5, because they were the first builds of the RST(e) series and have a lot of bugs (much more than v11.2.01006).

An up- or downgrade within the Intel RST Series (v9.x.xxxx until v11.2.0.1006) or within the Intel RST(e) Series (v11.5.x.xxxx until v12.8.x.xxxx) is no problem at all. Users, who switch from any "classical" RST driver to any of the more actual RST(e) Series, will get some changes within their Device Manager because of the SCSI filter driver, but will not run into troubles.
Problematic is only a downgrade from any Intel RST(e) driver version using the additional SCSI filter driver to any "classical" RST driver named iaStor.sys. Users may realize a remarkable decrease of their HDD/SSD performance, because the registry entries regarding the SCSI filter driver may still be present. In this case it is a good idea to open the registry and to delete the iaStorF entries. For details you may look >here<.

5

Much obliged for the help! As always.

Per your recommendation, I’ve ditched the 12.8 and jumped allllll the way back to 11.2 :slight_smile: I followed the instructions for the “downgrading” process that you linked, including removing the “iaStorF” from the “LowerFilter” key (but not removing the key itself). I also re-modded my BIOS with the appropriate OROM you mention (11.2.0.1527), and flashed it back. So I’m now using RST driver 11.2.0.1006 with OROM 11.2.0.1527.

Is there anything else I can or should do, as far as cleaning/maintaining/checking to see that the RST driver/OROM are fully functional and “healthy”? Particularly making sure that none of the v12’s are still hanging around or interfering in any way (I did delete both services and remove both .sys)?

Should I also verify that other Intel device/product/chipset drivers are correctly in place and working?

For example, whenever I install the latest Intel chipset drivers, one thing I do (that I’m not sure if I should), is “force” them in the Intel installer with the “Override/Overall” CLI switches. Afterward, I then go into Device Manager and do a manual driver update for all Intel devices, having them automatically search the extracted Intel chipset utility folder. This causes some drivers to update, like “Intel(R) ICH10 Family USB Universal Host Controller - 3A3A” (8 of these total that get updated). I figure that these are better off using Intel’s latest drivers than relying on Microsoft’s 2006 driver.

And then also, there’s another device, as well, that also takes a manual update (I think also from the extracted chipset utility folder) – I think it’s the Intel LPC Interface Controller – maybe there are even others (it’s been a while since).

Anyway – what are your thoughts on doing this? Is it preferable for one to “force” update drivers for the various Intel devices in Device Manager, or is the SATA controller the only driver that a person should really be doing anything with?

Thanks Fernando!


-----

EDIT:

Oh, and for anyone’s future reference – I dug around and found apparently why Windows Experience Index is reporting my SSD at 5.9 now instead of the 7.7/7.9 it’s been in the past:

Looking into the “winsat.log”, a few lines in the middle of the test read:

1
2
3
4
 
224620878 (8528) - winsat\main.cpp:1775: > Run Assessment disk -scen 2009 -drive C:
[i][b]224620894 (8528) - storage\diskprof.cpp:2324: Unable to open temporary file.  Largest available contiguous space was: 71MB[/b][/i]
224620894 (8528) - storage\diskprof.cpp:0283: Error: Failed to properly assess the disk.
The operation completed successfully.
 


This apparently stems from there not being enough unfragmented space on the drive to lay down a 1GB file. Others say that defragmenting the drive (yes, defragmenting an SSD) would condense fragmented files and allow for the 1GB WEI file test to be laid down, resolving the issue.

I realize WEI is an entirely useless and inconsequential metric, which rarely even sees the light of day, but I've got the little nagging OCD-bird on my shoulder, putting me down with that glaring "5.9" that used to be so much higher :/ Would it be that disastrous for me to defrag the drive so that this test could be run and have its old glory restored? :D


Oh, and as for an actual "real" benchmark, here's a benchmark run after the 11.2's were reinstalled yesterday: [attached]


EDIT^2:

Success! Manually running the disk portion of the WEI resulted in below (rather than the usual abrupt error and premature stop):

> Running: Storage Assessment '-scen 2009 -drive C:'
Mode Flags = 0x%08x
Disk Number = 0
Iterations = 1
IO Count = 9000
Sequential IO Size = 65536
Random IO Size = 16384

Requesting a file of size 1073741824 located at physical offset 0x12a4b80200.

Expected number of IOs: 9000
Number of IOs in trace file:9469
> Run Time 00:00:50.67
> Responsiveness: Average IO Rate 0.74 ms/IO 7.9
> Responsiveness: Grouped IOs 9.40 units 7.3
> Responsiveness: Long IOs 1.69 units 7.9
> Responsiveness: Overall 15.92 units 7.9
> Responsiveness: PenaltyFactor 0.0
> Total Run Time 00:00:51.40
> The System processor power policy was restored


Regarding the scores at the bottom, is there anything you can see that might look "concerning"? I don't understand those metrics as far as what would be normal (for my SSD and system). But I'm wondering if "Grouped IOs" is less than what it should be, given that it's apparently so far off the mark from the other metrics.

Crystal Disk Stats_11.2.0.1006_Sept2013.jpg

Crystal Disk Stats_11.2.0.1006_Sept2013_2.jpg

6

Open the Device Manager > "View" > "Show hidden devices" and search for a section "Non-Plug and Play Drivers". If such section is present, there should not be the iaStorF.sys listed anymore.

If the Device Manager doesn’t show any yellow mark and the iaStorF.sys isn’t listed anymore as Non-PnP Driver, everything should be fine.

Not really. The impact of the "Intel(R) Chipset Device Software" on the stabilty and performance of a Windows Operating System is absolutely overestimated by many users.
Here are some facts:
The "Intel(R) Chipset Device Software" (former name: "INF Update Utility") doesn’t contain any real driver (= .SYS files), but only text files. An installation or (forced) update of these INF files is harmless, but usually not needed, if the Device Manager doesn’t show yellow marks.
When a new "Intel(R) Chipset Device Software" package with a higher version number is available, many users do believe, that all included >150 Intel chipset INF files ("drivers") have been updated and will be "better" than the formerly installed ones. That is nonsense. Usually just the INF files for absolutely new (8-Series) or upcoming (9-Series) Intel chipsets have been added or really updated by Intel, when they publish a new Chipset Device Software package. You can easily verify it by opening specific INF files of different "INF Update Utility" packages". Very often just the INF file date has been changed - that is not a real "update", isn’t it?
Conclusion: The permanent (forced) installation of any Intel Chipset Device Software package is harmless, but usually will not have any positive effect on the system stability or performance. If you force the installation by the "-overall" command you may even blow up the C:\Windows\INF folder without getting any advantage.
Note: When you force the installation of a "newer" INF file, the old one will not been deleted. You will find all old and useless INF files named oemXX.inf within the Windows\inf folder.
It is an illusion to believe, that the chipset manufacturer Intel is still paying their employess for the development of newer and better drivers or INF files for old chipsets. They may just change some dates and will give the users the good feeling to have the "newest drivers".

7

Thanks much, great to know.

I have a grayed-out "iaStorA" entry in Device Manager (under the hidden Non-Plug and Play), but no sign of "iaStorF". Is this is alright? Or should I uninstall it? Thanks again.

8

That is alright and the iaStorA.sys driver should not been deleted from the Windows\system32\drivers folder.
Simple reason: Since the OS had used the iaStorA.sys before you "downgraded" to the RST driver iaStor.sys, the OS needs the iaStorA.sys for an emergency case, when you should decide to reset the system to a previous date ("last good configuration").

9



I would rather see Intel with a 2013 date then a 2006 Microsoft.

EDIT by Fernando: Quoted text corrected

10

That is alright and the iaStorA.sys driver should not been deleted from the Windows\system32\drivers folder.
Simple reason: Since the OS had used the iaStorA.sys before you "downgraded" to the RST driver iaStor.sys, the OS needs the iaStorA.sys for an emergency case, when you should decide to reset the system to a previous date ("last good configuration").



K. By the way, regarding the removal of the iaStorA and iaStorF services (per the external instructions for "downgrading" that you linked to) –

Why couldn’t I see them listed in the Windows Services manager? How come they were only accessible through the CLI, via the "sc" command?

This makes me wonder (and assume) that I have many other "hidden" services that are lurking somewhere, that haven’t been properly removed from the system.

11

I don’t know that either.