when I install, the date is 5.12.2014 and not the 2015 date you say it is?
tests show very little difference
About write-back caching: is this setting implemented on the driver level? And is it a RAID setting only?
A while ago I saved a failed RAID 0 array (with help from here) and have been using my two drives separately ever since. Now I’m wondering if write-back caching still active or not.
The Device Manager just reads the driver date from the related information file (xyz.inf). If you want to know the real driver date, you have to right click onto the driver file itself (here: iaStorA.sys) > "Properties" > "Details".
The feature "Write-Back Caching" is only available for RAID users, has to be done from within the Intel RST Console Software and will be active as long as the RAID array has not been deleted, whereas the "normal" Write Caching can be enabled for all disk drives (no matter if RAIDed or non-RAIDed) from within the Device Manager (right click onto the related Disk Drive > "Properties" > "Policies").
The correct date is the Signing (Digital Signature) date and not the Modified one. Here:
The correct date is the Signing (Digital Signature) date and not the Modified one.
That was the date of the internal digital signature given by Intel. Microsoft has given their WHQL stamp on 9th of January 2015. Look here:
So the driver itself may have been compiled on 5th December 2014, but the final steps were done by Intel on 27th of January 2015.
The way I see it, Microsoft is a "3rd party" in this case, the actual driver is Intel’s so the important date is the compilation one (that’s the date that the .inf files include and is shown at Device Manager). There are also non-WHQL drivers, Intel is important not Microsoft. The final step done at 27/01/2015 is basically copying & packaging the files before release.
Similar to ME firmware, the actual .bin inside the official .zip package from their site may show a date of 05/01/2015 but the actual firmware a date of 31/12/2014. The correct date is the latter, compilation not PV release.
This is what I expect as well, but unfortunately the users cannot always trust the INF files entries, which are shown by the Device Manager.
Example:
Here are the first lines of the 64bit ISCTD.inf file, which you can find within the attached original Intel Smart Connect Technology (ISCT) driverpack v5.0.10.2936 WHQL:
Please compare the red marked INF file entries with the reality:
Note: A wrong driver version and compilation date shown by the Device Manager may not even been recognized by many users, but I was wondering why I was not able to get the 64bit ISCT Driver v1.1.0.0 WHQL installed while running Win 8.1 x64 until I realized the wrong [Intel.NTx86] entry within the 64bit INF file.
What you have written may have been valid in the past, where the hardware manufacturers have sent the finally compiled drivers to Microsoft, got them back a few days later with a WHQL signature within the .CAT file and released them without touching the SYS and INF files again.
Nowadays it seems even possible for the hardware manufacturer to silently update an already finally compiled driverpack.
Intel SCT Driver v5.0.10.2936.rar (53.5 KB)
That is indeed some sloppy work by Intel, total screw up (wrong version and wrong architecture). It’s not the norm though, this looks like a one-time thing. For everything else (that works as it should), the digital signature will give you an accurate estimation of the file’s date.
This should not be possible to my knowledge, it would defeat the whole purpose of digitally signing a driver. When MS signs a package, every file inside (.inf, .sys) is hashed and RSA-encrypted via Public-Private Key inside the catalog file. It’s called thumbprint. If Intel tries to modify the .sys or .inf files after receiving the signed catalog file from MS the latter will automatically become invalid. Details.
Do you really believe, that any MS employee is checking the content and functionality of the SYS and INF files before giving the WHQL stamp?
I have seen complete series of different NVIDIA Ethernet drivers (all of them WHQL certified) with exactly the same wrong INF file entry.
When chipset manufacturers like Intel or formerly NVIDIA are going to create the matching INF files for a freshly coded new driver version of a certain development branch, they just copy and paste the INF file content of the previously released drivers and change only the driver version and date. I doubt, that they will update the related INF file entries, if they should realize and correct later on a wrong code within the SYS file.
MS doesn’t care about that, the signing is done automatically. If an OEM gives them a "broken" inf file it will still get hashed and then added to the catalog file encrypted. It’s a separate procedure. An OEM can indeed just copy-paste the previous .inf file, change the version and then send it to MS for WHQL signing. The resulting catalog file from MS will include the hash of the inf file provided by the OEM. After MS signs the contents of the package (.sys, the broken .inf etc) the OEM cannot alter them (to fix the broken .inf for example) without breaking the previous certification. They would need to re-sent it to MS to get signed again. I never said that we should check the .inf file but rather the digital signature of the .sys file. If the OEM spotted an error at the sys file after it was signed by MS, they would fix it first (new digital signature) and then re-send it to MS.
@ plutomaniac:
You may have misunderstood me.
I have never argued, that Intel may have modified the content of their driver files after having gotten the WHQL stamp from Microsoft.
What I wanted to point out is, that
a) the Device Manager just shows the version and date of the driver, which is layed down within the related INF file - regardless if these entries are correct or not - and
b) these INF file entries may be wrong.
Undoubtedly Intel has done something with the files of the RST(e) drivers v13.6.2.1001 on 27th of January 2015. Otherwise they wouldn’t have gotten a new date. A simple packing procedure doesn’t alter the dates of the affected files.
Now we should stop this off-topic discussion.
this is your modded driver results,
which is the most important one to pay attention too?
It depends on the size of the files, which are mainly or very often read resp. written with your computer.
For the daily work of a "normal" user the most important benchmark results are the 4K ones, but for video encoding tasks the "Seq" and "4K-64Thrd" scores may be important as well.
Hello Fernando,
Do you know what sort of Intel drivers are best for the new X99 chipset?
Would like to enable RAID 0.
AFAIK, I was using the latest version: >Intel RST(e) AHCI/RAID Drivers & Software Set v13.6.2.1001 WHQL, However I just saw the new (to me) drivers: >64bit Intel RSTe AHCI/RAID Drivers v3.8.1.1006 WHQL for Win8/8.1 x64
I have downloaded the v3.8.1.1006 and I could not find the setup.exe application to install the Intel RSTe Software, I could only see the drivers need to load up while you are installing windows.
Thanks for your help.
If your mainboard BIOS offers the option to switch from RSTe to RST, I would install one of the RST(e) RAID drivers of the v13 series.
Please read the complete RSTe drivers section of the start post. Then you will find, what you are searching for.
I have no idea of my board offers the option to switch from RSTe to RST,however I’ve seen at the Asus website that I can download the Intel Rapid Storage Technology Driver software V13.1.0.1058,that leads me to believe that you might be right.
http://www.asus.com/au/Motherboards/RAMP…pDesk_Download/
Thanks.
The Intel RST drivers v13.1.0.1058 do indeed support the original X99 chipset Intel SATA Controller, but only in AHCI and not in RAID mode.
Then the Intel RST(e) AHCI/RAID Drivers v13.6.2.1001 will just suffice to run RAID 0 on a X99 system chipset?
Thanks
There are at least 2 options to get any Intel RST(e) RAID driver v13.x.x.xxxx installeed onto an X99 RAID system:
a) You set the Intel SATA RAID Controller to "RST" within the BIOS (this option requires to BIOS ability to switch the DeviceID from DEV_2826 to DEV_2822).
b) The other option is to install an Intel RST(e) RAID driver v13.x.x.xxxx, which has been modified by me. You can find them >here<. In this case you will use the original DeviceID (DEV_2826) of your on-board Intel SATA RAID Controller.
Hi Fernando,
I have downloaded your modded RAID Drivers, however can you explain what do you mean with this:
" have to be installed manually from within the Device Manager, only usable with Win7 x64 and - after having disabled the driver signature verification - Win8 x64)"
AFAIK, I thought I could load up your modded drivers while doing the windows 8.1 Pro installation and once the windows it’s all installed, I would just need to install the Intel RST_64 console and voila! Al done, but it seems that because these are modded drivers, I need tro install them in a different way.
Can you please share the right sequence to install your modded drivers?
Thanks a lot.