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):

<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):

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

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

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.

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 :) 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:

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.

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.

Zitat von Fernando im Beitrag #6

---

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

---

Zitat von Fernando im Beitrag #8

---

Zitat von Coldblackice im Beitrag #7

---

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?

---

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

---