Z77, Z68, P67, X58 are just few examples of popular chipset that has ICH10R inside.
Z77, Z68, P67, X58 are just few examples of popular chipset that has ICH10R inside.
i5 2500K (L041C124) @ 5GHz + Scythe Mugen 2 rev. B | ASRock P67 Extreme4 B3 UEFI L3.19 | ADATA 2x4GB DDR3 1600 | MSI Radeon RX 470 4GB | 2x Crucial m4 64GB SSD RAID 0, Seagate 7200.12 500GB, Samsung F4 EG 2TB | 24" HP LP2475w | EVGA SuperNOVA G2 750W | Fractal Design Define R3 | Windows 10 64 bit
Then you are wrong apparently. Z77 is no different than Z68 in terms of SATA controller.
As for now release notes for RST 11.5 WHQL are missing and no official info was given about TRIM in RAID 0.
Your experiments does not prove anything.
BR,
i5 2500K (L041C124) @ 5GHz + Scythe Mugen 2 rev. B | ASRock P67 Extreme4 B3 UEFI L3.19 | ADATA 2x4GB DDR3 1600 | MSI Radeon RX 470 4GB | 2x Crucial m4 64GB SSD RAID 0, Seagate 7200.12 500GB, Samsung F4 EG 2TB | 24" HP LP2475w | EVGA SuperNOVA G2 750W | Fractal Design Define R3 | Windows 10 64 bit
Intel Core i9-7980XE@ 4.8GHz 18C/18TH (Direct Die Contact)
ASRock X299 OC Formula
ADATA XPG SPECTRIX D80 (4x8GB) DDR4-3800C17 B-Die
1x Intel Optane SSD 905P 480GB
4x HP EX950 NVMe 2TB on ASRock ULTRA M.2 CARD
EVGA RTX 2080TI KINGPIN 2190/8000 Stock Cooling AIO 240
SilverStone ST1500W-TI TITANIUM
Alphacool Custom Water Cooling
Asus Rampage IV GENE
i7 3930k
8 gigs Mushkin 2133
HIS 7970
2x OCZ Vector 256gb raid0
Crossover 27Q
you guys should be lobbying intel for their intel here. on one hand we have MS saying 'no win7 trim', and intel saying 'raid trim', but not delineating which os they claim trim to be working under, though just because the drivers are for several os do not mean that win7 is in with win 8, unmap wise. trimmed data should not be zeros, it should be ones or 0xFF. i hope intel put out a clearer message as to what they are claiming...
Asus Rampage IV GENE
i7 3930k
8 gigs Mushkin 2133
HIS 7970
2x OCZ Vector 256gb raid0
Crossover 27Q
If there is no difference in terms of SATA Controller, why do the SATA AHCI Controllers have different DeviceID's (DEV_3A22 = "Intel(R) ICH10R SATA AHCI Controller", DEV_1C02 = "Intel(R) Desktop/Workstation/Server Express Chipset SATA AHCI Controller")?
If you run the RST Console Software of the latest official Intel RST driverpacks and hit "Help" > "Introduction" you can see the required "official info" given by Intel about TRIM in RAID0:Originally Posted by radierEverything clear?Originally Posted by Intel
I trust my own experiments more than any info of a vendor, who primarily wants to earn money.Your experiments does not prove anything.
clear? no. no os is mentioned, and it would rely on the unmap commands sent down. why do you think we are seeing 'scsi' even for single drives? the drivers will pass through an unmap command, but there isn't one from win7.
Asus Rampage IV GENE
i7 3930k
8 gigs Mushkin 2133
HIS 7970
2x OCZ Vector 256gb raid0
Crossover 27Q
Win7 is not able to send the UNMAP command, but the Intel SCSI filter driver iaStorF.sys is able to change the Trim command to an Unmap command. That is the reason why Intel is now using 2 drivers simultaneously (iaStorF+iaStorA.sys), whereas the "normal" Intel MSM and RST drivers always had just 1 single driver named iaStor.sys.
Intel Core i9-7980XE@ 4.8GHz 18C/18TH (Direct Die Contact)
ASRock X299 OC Formula
ADATA XPG SPECTRIX D80 (4x8GB) DDR4-3800C17 B-Die
1x Intel Optane SSD 905P 480GB
4x HP EX950 NVMe 2TB on ASRock ULTRA M.2 CARD
EVGA RTX 2080TI KINGPIN 2190/8000 Stock Cooling AIO 240
SilverStone ST1500W-TI TITANIUM
Alphacool Custom Water Cooling
Any issue with loading the 11.5 rom on an x79 bios?
where do you get this? quite an assumption. you would need two drivers anyways: trim hint and unmap hint passthrough. single ahci+trim/ahci driver, raid would need unmap, hence the scsi. where are you getting documented info that drivers are 'converting' trim to unmap hints, and the os is oblivious to this? i know some are bandying about the idea of a low stack driver, but this is not taking into consideration the os's part, and i have not seen any working examples of this anywhere on earth documented as working. you are making a rather big assumption, and i would like again to know what you are basing your opinion on. i can find ms docs showing that win7 will not and can not pass unmap, and that it would take the os to have that in it's api, but i can't find any bona fide info re drivers creating unmap out of basic trim hints. please share...
Last edited by m.oreilly; 07-29-2012 at 04:23 PM.
ok, i'll toss out a bone. yes, there have been manufacturers that have demonstrated trim capable raid controllers, but the required windows api was not going to be changed on ms's side...some time passes, and we see win8 getting all perky and including unmap. intel is a big player, as is MS in the now burgeoning solid state storage/server market. it has to be seamless in execution, and with what we got in the pot as players, it may take some more umpf to get 'magic' drivers in place. when we see lsi and areca touting win7, or really, server 2008 r2 unmap passthrough, i'll be a believer al la that win kernel/magic drivers are here.
Asus Rampage IV GENE
i7 3930k
8 gigs Mushkin 2133
HIS 7970
2x OCZ Vector 256gb raid0
Crossover 27Q
ok , another bone toss. you have computurd here. sorry for the tug, but you could ask him if areca or lsi are passing on server 2008 r2 unmap drivers. sorry comp, but intel consumer boards running win7 getting raid trim above server class(?) just doesn't sit right...
Asus Rampage IV GENE
i7 3930k
8 gigs Mushkin 2133
HIS 7970
2x OCZ Vector 256gb raid0
Crossover 27Q
TRIMmed data is generally whatever the controller chooses it to be. Most SSDs do not have a static LBA to physical address mapping scheme like hard drive do .... so what happens is that the SSD actually creates the mapping between LBAs and physical locations when you perform writes. This avoids the read->erase->rewrite operations that caused so many latency problems with old jmicron drives. This means, that if you haven't written to a particular LBA number, then there is nowhere to read it back from. Thus the controller simply creates a fake sector with whatever data it wants (FF or 00)
When you secure erase a drive, or delete files off it with TRIM, you are also eventually removing the LBA mapping for the sectors you are erasing. This means again, that the drive must create a fake sector if you then attempt to read it.
Have you noticed process IAStorDataMgrSvc.exe ?
It is consuming memory step by step.
i5 2500K (L041C124) @ 5GHz + Scythe Mugen 2 rev. B | ASRock P67 Extreme4 B3 UEFI L3.19 | ADATA 2x4GB DDR3 1600 | MSI Radeon RX 470 4GB | 2x Crucial m4 64GB SSD RAID 0, Seagate 7200.12 500GB, Samsung F4 EG 2TB | 24" HP LP2475w | EVGA SuperNOVA G2 750W | Fractal Design Define R3 | Windows 10 64 bit
i assume 0x00 is a programmed state. which drives under what conditions report 0x00 as clean nand? i'm hoping you guys have really hit on something here, but i'm just not getting enough documentation that points to what you are claiming. i wish intel would be a little more forthcoming. i don't understand why they wouldn't be, but until they do, i really can't drink the coolaid...
Asus Rampage IV GENE
i7 3930k
8 gigs Mushkin 2133
HIS 7970
2x OCZ Vector 256gb raid0
Crossover 27Q
Hello everyone!
I have subscribed to this forum and spent one dollar just to inform you there is an updated ROM, version 11.5.0.1582 available!!!
I contacted Biostar requiring an update to the OROM for the motherboard of the server of my gaming center. The mobo is T5XE CFX-SLI, P55 chipset. It was abandoned quite some time ago and left with OROM 9.5.x.xxxx. I asked them to updated BIOS so OROM was brought to the most recent version, and they sent me a new BIOS with the mentioned version.
I sent another email asking if 11.5.0.1582 is the latest stable release and they replied saying soquete 1156 mobos are discontinued and that every update is special and beta only, no support. We'll have to wait until Intel updates their own current mobos so we know which OROM is indeed latest. At least this one I offer is more recent.
Now, I don't know how to extract the OROM from the BIOS file, but I give you the link they provided me with so you can extract yourselves. Whomever manages to do extraction, please provide community with public link so everyone can download! Yes, it's OROM 11.5.0.1582 and proof follows by pictures I took during boot. It even works on P55 (soquete 1156) PCH.
I was shocked, astonished, that I got a positive reply, I mean, I'd never ever expect that they'd update the firmware just for me! OMG! I'm sooooo happy!
Also, there is one thing I noted: they changed recommended strip size for RAID0 arrays. It used to select automatically 128KB, now it chooses per se 16KB. OROM screen below shows 8KB strip, but that's because I used that array with OROM 9.5.x.xxxx before and in my test that's where I achieved maximum performance. I've reformatted the HDD's, now I use 16KB and 16KB NTFS cluster ("unit") size on all partitions.
This is the link:
http://206.108.48.66/temp/Eric/P55DA726.zip
IMG_0017.JPG
Last edited by medeirosdez; 07-30-2012 at 11:34 PM.
FYI:
I just have tested, if the presence of the new Intel RAID ROM module v11.5.0.1582 does change anything regarding the Trim support of an Intel Z68 chipset RAID0 array.
Result: It doesn't. The sector with the freshly deleted file didn't zeroed out. The original Hex data were still there.
i think you guys are relying on the hex 'results' a little too much, especially with multi drive lun and single/'shared' lba. both drives you mentioned are sandforce based, and with their inherent encryption/lba jiggery pokery, i think you would still be looking at programmed with 00 returned...still not buying it...
Asus Rampage IV GENE
i7 3930k
8 gigs Mushkin 2133
HIS 7970
2x OCZ Vector 256gb raid0
Crossover 27Q
Bookmarks