Vertex 4 Reviews and Thoughts

[squick3n]

The stuff they had people doing when the V3 came out was so absurd. There was some 15 step OS install process that required a whole bunch of restarts and did absolutely nothing. That said, when they finally got it sorted out, I though the V3 MI was a really good drive. Pretty cheap on Amazon right now as well

[tbone8ty]

anybody test new firmware yet?

[lm358]

anybody test new firmware yet?

http://www.storagereview.com/ocz_ver...firmware_v14rc

[tbone8ty]

hmm damn ocz has a hard time making a stable firmware at least its a good step...ill have to wait and see on this

need a vertex4 128g review vs samsung 830 128g

[Highendtoys]

Firmware Updates with 1.4 RC4 - RC4 is what reviewers recieved to test with.

http://www.tweaktown.com/articles/47...4rc/index.html

128GB with 1.4 RC6 - RC6 is what OCZ published on their webpage. It fixed some issues. I'm not sure if it fixed the issues SR ran into.

http://www.tweaktown.com/reviews/471...are/index.html

[Anvil]

I got one today, I'll update to the latest RC prior to doing any tests, will read up on what issues SR found.

[Anvil]

The firmware update (1.4RC) didn't take on the X79 3 series driver.

It worked straight away on an Z68, no writes done before updating. (except for what ever was written before I got it)
The fw is destructive and did clear the SMART values.

[Highendtoys]

I had to update on the Marvell ports.

[Anvil]

I'm not sure I've got the Marvell ports enabled on the X79. (not sure that there are Marvell ports, think it's ASMedia)

I try to stick to the Intel ports!

[Ao1]

So what's going on with the V4? Pre-f/w update and canthearu gets ~150MB/s in the endurance thread. Post f/w update and canthearu gets ~125MB/s. The SSD Review of the new f/w shows that write speed drops from ~380MB/s to ~100MB/s after 50GB of writes.

On the AIDA 64 bench the write speed "flat lines" once speed drops to ~100MB/s. Is this a more subtle form of throttling? What happens if you stop writing after the speed drops and wait a while before continuing to write?

[Anvil]

I'd like to see what happens running such a test on a 256GB drive, would the drop in speed start at ~128GB or occur at all?

Still, the fw is a RC so there will surely be issues. (looks like that one could be a prime candidate)
I'm sure there is some reasonable explanation.

[Highendtoys]

The second half drop has me perplexed too. I didn't get it when testing any of my three drives but Bill Gates has the issue with his 128GB. Until I started getting his numbers I just thought it was something with SSDR's drive. Hopefully I can fire my 128GB back up tomorrow and see what's going on first hand.

[canthearu]

So what's going on with the V4? Pre-f/w update and canthearu gets ~150MB/s in the endurance thread. Post f/w update and canthearu gets ~125MB/s. The SSD Review of the new f/w shows that write speed drops from ~380MB/s to ~100MB/s after 50GB of writes.

I've noticed the same thing, except on my drive it is more like 20gig after each loop begins. I posted a graph of the disk speed on the endurance thread as each loop happens.

I don't really think it is throttling, just the drive running out of blank NAND and having to go into a scavenge/recover mode. The really high speeds are the drive simply writing at full trot but not doing ANY garbage collection. Once it runs out of free NAND, it has to work twice as hard to clean NAND.

I'd be curious to see what happens if I could pause ASU for a minute half way through the loop, then let it continue.

IMO, I'm not much of a fan of the new firmware. Would rather slower, more consistent performance.

[Anvil]

I have tried pausing and it doesn't help on getting the speed back up! (in general, idling has no effect, on my drive that is)
(there are ways of getting the speed back up though)

Just a thought, what if you extend the pause between loops by just a few seconds, say 12000 or 15000 (12-15 seconds)
I expect it could help on the speed, the default 10 second pause might just not be enough for TRIM to complete.
How much space is left on the drive at the end of the loop, the default 12GB?

I think we need to keep in mind that the FW is a Release Candidate, issues are to be expected!

[Ao1]

I've noticed the same thing, except on my drive it is more like 20gig after each loop begins. I posted a graph of the disk speed on the endurance thread as each loop happens.

I don't really think it is throttling, just the drive running out of blank NAND and having to go into a scavenge/recover mode. The really high speeds are the drive simply writing at full trot but not doing ANY garbage collection. Once it runs out of free NAND, it has to work twice as hard to clean NAND.

I'd be curious to see what happens if I could pause ASU for a minute half way through the loop, then let it continue.

IMO, I'm not much of a fan of the new firmware. Would rather slower, more consistent performance.

Considering the new f/w is supposed to be around 380MB/s for large block writes there should have been a significant increase in the speed of the endurance testing. Instead it has reduced. nDurance (throttling?) a significant change in GC (?)/ a f/w glitch (?) It would be good to understand what has to happen before write speeds get back to normal. If you wait for the write speed to drop using the AIDA 64 bench and then bench with ASU or AS SSD does the speed go back up? How much idle time is required before write speeds recover?

[canthearu]

Just a thought, what if you extend the pause between loops by just a few seconds, say 12000 or 15000 (12-15 seconds)

I've already tried this, doesn't make a difference.

[Highendtoys]

OCZ knows about the issue and is looking into it. Gates sent a bunch of info and test data over.

[Anvil]

Looks like 1.4 final could be out!

I've performed some testing and benchmarks are if anything up a bit.

I have not tested the "50% full slowdown" issue yet

edit
Forgot to mention that in my case the update was destructive.

OCZ-VERTEX4_128GB_1GB-20120519-1159_edited.png

as-ssd-bench OCZ-VERTEX4 5.19.2012 12-04-58 PM.png

[canthearu]

Can you test for me Anvil .... I'll definitely upgrade right away if the performance issue is fixed!

[Anvil]

I've replicated my last test (on the slowdown issue) and it shows no difference.

Performance wise there is no need to update, could be other things that are fixed though.

[Christopher]

Its not a design flaw, or a bug, or some unintended consequence. Smaller sequential writes seem to be "immune" to an extent, but I can't do any further testing at the moment.

[Ao1]

Its not a design flaw, or a bug, or some unintended consequence. Smaller sequential writes seem to be "immune" to an extent, but I can't do any further testing at the moment.

I still don’t get it. Is it:

a) If the drive is 50% full read and write performance drops?
b) If you write 50GB of data in one hit performance will then drop?

If it’s a) does performance drop linearly depending on how much static data the drive has, or is there a tipping point at 50%?

If its b) what has to be done to recover read/ write speed?

This only happens on the 128GB drives?

If its not a design flaw/ bug/ unintended consequence is it how the drive is designed to behave?

[Christopher]

No, I think whatever they had to do to juice up writes that much results in some unusual characteristics. All I mean is, I wouldn't think 1.4 final would "fix" it.

[Nizzen]

OCZ:

...have reported many issues that have not made 1.4...they will make it into future FW builds

Wait for Vertex 5, the wait for vertex 6, and so on.

If you want to wait, then buy OCZ

Before Vertex 4 came out, I guessed that it would be 17 firmware updates before it is "bugfree".... We are soon there :p

[Ao1]

No, I think whatever they had to do to juice up writes that much results in some unusual characteristics. All I mean is, I wouldn't think 1.4 final would "fix" it.

I’m going to guess it’s a form of throttling then. Makes sense looking at that graph; a sudden drop and then more or less flat line performance.

Maybe it is also why you can see less of an impact with smaller sized xfers if the throttling is based on a bandwidth restriction. If I remember correctly the SF drive also throttled reads, which was presumably linked in some way to the mechanism that throttled writes. Is read performance also impacted when write speeds drop?

It’s not actually that unreasonable if you need to protect a 5 year warranty against server type “abuse”, but “if” true $OCZ should be upfront about it.