If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The reason why 120gb OCZ agility beats 60gb OCZ vertex is because they are different sizes.

Yes.

Thanks for pointing out these obvious flaws in this benchmark. Very, very sloppy.

Also to note is that the 1.30 version of OCZ SSD firmware for the Agility and Vertex introduce a concept called "Garbage Collection". The GC routines kick in when the drive is otherwise idle and is used to organize/collect data on the flash so that it will be able to do it in the most efficient/fastest way possible. The 1.30 firmware has a very early version of GC that can take a lot of idle time to take effect. The next released firmware should be much better in this regard. PCPer has an article which tests an early release of this new firmware which shows how it can help.

At the very least, both SSDs should have been wiped clean using the tools available from OCZ to make sure both were in the same starting state.

Comment

TRIM is supported by ext4 (dunno about ext3) since Linux 2.6.30 or 2.6.31. But there is still no SSD avaible that supports this command. Firmware updates for Intel and probably the Indilinx are coming September/October-ish.

While technically true, it's not the whole truth. While ext4 (but currently not ext3) does issue TRIM commands in what the developers believe is the correct places, the VFS layer in the kernel does not pass it down to the drive, as that is considered dangerous to do without testing it on actual hardware. So just updating the firmware when it's released won't be enough, you'll need a new kernel too. The VFS will defenitely not get TRIM support before 2.6.32, most likely not until 2.6.33. So most end users won't see it until the Spring 2010 release of their favorite distribution.

Comment

Also to note is that the 1.30 version of OCZ SSD firmware for the Agility and Vertex introduce a concept called "Garbage Collection". The GC routines kick in when the drive is otherwise idle and is used to organize/collect data on the flash so that it will be able to do it in the most efficient/fastest way possible. The 1.30 firmware has a very early version of GC that can take a lot of idle time to take effect. The next released firmware should be much better in this regard. PCPer has an article which tests an early release of this new firmware which shows how it can help.

Well, garbage collecting is great, but if all logical blocks are written to neither write combining nor garbage collection will be very usefull, as ther will be no room to manouver in. And without TRIM support all logical blocks will be written to in relatively short order (depending on disk usage of course). Combining this with TRIM support in a future firmware release will be great though. Perhaps even enough to match Intel X-25 M G1 performance, though only time will tell for sure.

Comment

Well, garbage collecting is great, but if all logical blocks are written to neither write combining nor garbage collection will be very usefull, as ther will be no room to manouver in. And without TRIM support all logical blocks will be written to in relatively short order (depending on disk usage of course). Combining this with TRIM support in a future firmware release will be great though. Perhaps even enough to match Intel X-25 M G1 performance, though only time will tell for sure.

I don't know - it seems like the PCPer report shows that as long as the drives have enough time to GC, it is enough to regain full write performance. Is it less than optimal? Probably - I'd imagine that with TRIM support less time will be needed for GC.

Comment

That's because a 120G drive has perhaps 130G of blocks available to it.
This extra space (I don't remember the exact amount of extra space given) allows the drives to write and move blocks about if it needs to combine many blocks to delete them etc, speeding it up.

When dd-ing a drive a couple of times over, this area will probably get eaten into - while dd-ing a fresh drive only once will leave this spare space alone.

You also have the firmware storing reference tables etc, and the more that get's messed up, the worse the performance is (another thing I guess 'GC' does on the newer firmwares).

I've only JUST got 2 30G vertex drives right now (afraid to partition/format them as I'm not 100% sure if I have the 512K alignment correct) - and if these drives are as good as they look then I might get 2 of these and compare - although for a PC you'd want drives around the 120G mark.
I could do some preliminary file creation / random file copy tests from a ramfs filesystem (so you get rid of that useless read / CPU bound problems) like I did to test my current Core2 (yes, I know - but they're RAID-ed and I'd prefer the nice new Vertex's in my laptops ta :P).

It strikes me as odd that a Vertex couldn't out-perform a normal rotary drive in a few of these tests - it screams "something wrong here" to me.