Well I installed windows etc. but something still very wrong. Running AS SSD i get Seq (Read/Write) 139Mbs/72MB/s 4k 14MBs/56Mbs 4-64thrd 18MBs/68Mbs Acc .108ms/.319ms These speeds are way slower than those of the reviews online. AHCI is on, its plugged into the SATA port 0. Anybody got ideas?
Didn't we warn you ? Don't hammer the drive with benchmarks. You probably run few benchamarks, you used up the provisioning area with those benchamarks, so the safeguard kicked in. http://www.ocztechnologyforum.com/f...es-with-a-brand-new-SandForce-based-ssd-drive
Been a while since I was on the ocz forum. Lol they seem pissed with poor review tatics and thrashing of the drive. Lol go get um
Quick thoughts... - By the 1st SATA port, you should be looking at the intel ones not the JMicron ones... - You should install the intel RST driver as this is faster than the MS one - though bear in mind that the ver 10 ones are not yet compatible with the OCZ toolbox for f/w updating... Either you need to go for the ver 9 ones or accept that you can't update the f/w using the toolbox until OCZ sort it out. - & use ATTO for repeat initial testing (within reason) as this will give you a much better idea of if you've got things set up properly without writing the foolish amounts of data that AS-SSD & CDM do... ...that the latter 2 are 'designed for SSDs' simply means that they are better at giving artificial b/ms for comparative purposes than others 'designed for HDDs' not that they should be run regularly - esp as, a single run of both of them on default settings will write around 60-70GB (if i'm remembering correctly) for no good reason. Yeah, so if you must, leave AS-SSD & CDM until after you've got things running smoothly in ATTO.
No, not even ATTO. No benchmarks, period. What is so hard in understanding that by running the benchmarks right after install, you hammer the drive and set it in safeguard mode ? You just installed Windows 7, that means ~15GB data. Then you ran AS SSD, that means another few GB of data. With OCZ Vertex 2 120GB, your provisioning area is 8GB. You exceeded that just by installing the OS itself. Give the drive time to recover.
What utter BS... First off - the OP area isn't a specific set of cells, so - "You just installed Windows 7, that means ~15GB data. Then you ran AS SSD, that means another few GB of data. With OCZ Vertex 2 120GB, your provisioning area is 8GB. You exceeded that just by installing the OS itself." - is actually more like (keeping things as simple as possible & using your figures except where they're completely wrong) - "You installed Win7 so ~15GB (plus a GB or two for the install process). Then you ran AS SSD (either that & CDM writes more than the other, but for the sake of keeping things easy let's pretend it's ~35GB) ~35GB, so you've written, for argument's sake, 52GB of data to your SSD... With OCZ Vertex 2 120GB, this would mean you've written to ~43% of the total nand - ~15GB of which is actual data, leaving ~38GB to be recovered & 75GB (inc the OP area) clean." [Edit - NB this assumes that no trim or GC has occured in the intervening time which would reduce the no of dirty blocks & increase the clean capacity.] However, none of this has anything at all to do with the 'safeguard mode' as you term it (aka the bit of 'durawrite' which protects the SFs from excessive writes over a short period of time by temporarily slowing things down for a number of days) which, from other people's testing back when the drives first appeared, is significantly more than several times the free (ie blocks without data) capacity of the drive (though exact figures are under NDA). [Edit 2 - NB as the 'excessive writes' don't have to be all at once, this is a reason for the overnight S1 log off technique 'if' you do write very heavily] This isn't to say that (esp) the read speeds won't slow down temporarily on a V2 until the drive's had a chance to recover once all the blocks are dirty - on non SFs you get a similar slowdown in the same situation, but that tends to be more pronounced with reads writes as well as writes reads. in this situation, it's down to the ability of the drive's implementation of trim & (/or in non-trim environments) GC to recover. [NB see post 33 for clarification] Now, when you first install a SSD (or change/upgrade something like the motherboard/raid card where a material change has occurred) you need to know that things are working properly & so of course you need to run b/ms - & to suggest otherwise is just foolish otherwise you're risking having (comparatively) shonky performance & never knowing. What you do ideally want to do though is minimise the total writes by using the lowest impact b/m in terms of actual writes (aka ATTO) for the basic testing & then perhaps, once that looks correct & if you really must, a AS-SSD or CDM run to verify things. Once you've gotten all of this done, you should never have to do it again with that SSD; unless again you change/upgrade something like the motherboard/raid card which requires new testing to verify that everything's working as it should. Of course, this isn't to say that if you have needed to run (or randomly chosen to run) bunches of b/ms that a Secure Erase & reinstall of the OS wouldn't be unreasonable - since of course this returns the drive to the cleanest possible state - but you'd have had to have been doing something really OTT to make this essential.
Unless I'm mistaken, the Vertex 2E is a Sandforce drive, and AS SSD uses un-compressible data for benchmarking, so it's not likely to show the speeds you expect. Sandforce relies on compressible data to deliver the top end speeds - which ATTO has.
As Pocketdemon has already pointed out, you're spouting total nonsense. OP, the reason AS SSD is returning those results is because that is the Vertex 2's speed when handling non-compressible data. Bench with ATTO disk benchmark, and you'll see the drive's compressible data speeds, which will be uber. If you'd read the Vertex 2 review on bit-tech, you'd know this!
No... With AS SSD these are incredibly low - which is why i suspect the OP's used a JMicron port not an intel one... With the 2Xnm 32Gb die variant (Edit - which is what 'should' be in the supply chain) the 120GB 'should' b/m @ - (image half-inched from the OCZ forum) - & if it's a 3X nm one then it'll be quicker, [Edit] esp on sequential writes. (i have no idea which the OP has). Wow... We actually agreed on something about SSDs.
Had my SSD for over a year now and having initially checking that TRIM was active I haven't really done anything with it but the speed is still holding up.
Well then sorry for misunderstanding the sticky posts at OCZ and Corsair forums and other websites. Still, it is better not to benchmark the drives, instead of that copy a DVD image or some other big file, and you will see the real transfer rate.
Having just scanned the OCZ sticky, i think your confusion is down to the initial post then being ammended later in the thread. Well, in this thread we're talking about a specific situation of a clean install & then b/ming &, as the clarification states - "when new all Duraclass does when a write is requested is pick a fresh clean block to write too....this write reflects the new fresh clean state of the drive, but NOT the day to day running speed. With normal use Duraclass will push each and every write request to a new clean fresh block UNTIL they are all used up. Once they are all used the drives now has an active map of each block, it can tell which blocks have been used the least, which blocks have been moved to the OP area and which blocks it may rotate data onto during idle time to even out wear levelling. This day to day running state is really the write speed to the OP area of the drive, as this is where all writes are directed. An issue comes when you write to much data to the drive to quickly and you fill the OP area and overspill onto normal non OP area nand, what happens now is the drive starts to erase blocks marked by TRIM and push them to be available for the data you are writing. In your case as OSX does not have TRIM yet (no idea what apple are waiting for) the controllers own wear levelling map is used and least used blocks are cleaned ready for a write (which is pretty much what TRIM marks anyway) This is why its important if you wish to retain day to day running speed you do not hammer the drive with writes, OR you use a drive with more OP area, OR you add some capacity to OP manually." What this means is that, whilst you'd be correct that in day-to-day use you shouldn't be hammering a 1X00SF drive with b/ms, a day one installation is the perfect time to run b/ms (up to the total capacity of the drive minus the data usage) as it will in no way limit the drive. Whilst i appreciate that i should have made this clearer in my comment, this is part of the reason why i said that using ATTO for initial testing/problem solving (before (if ever) double checking with AS-SSD or CDM) is the better practice since it writes far less data; both of itself & because it's 100% compressible. & very separately, just to note, this also shows how good giving the 1X00 SFs extra OP is within heavier write environments. [Edit] As an example, my 4x 50/60GB V2s are set up as a 184.3GB R0 array (ie ~28% OP per drive)... ...this means that, once every block has been written to (having just SE'd for my Sandy Bridge build then that won't be instantaneously), i could write ~71.7GB in one go (without leaving any time for the drive to recover) with no negative effects.
Many thanks to all who helped me with this. I think i fixed the major issue with it. It turned out that where the BIOS said AHCI was on, it lied. I had to enable it elsewhere in the BIOS too, then let windows set up the drivers. Good to know that I can run benches. Was a bit at a loss as how to check that I had fixed it while being told not to run benches! I'll run ATTO to check that its all fine when i get home, and will report back if i'm still having trouble.
Over the weekend I cloned my bros primary drive to a Coarsair F60. Used SSD Tweak to change the essential settings and now all is runnng sweet.
