Vertex LE vs Crucial C300

i don't know what to tell you, this ONFI 200MBps still sounds strange,
yet your ROC idea, afaik, just seems briliant.
why didn't any manufacturer did that,
are they all stupid :confused:?
obviously such device/drive would be sold out on it's first week on the market,
i don't know if u've heard about it but, Intel's shipment of the 980 (~1100$+) chip has been sold out back a few weeks.
the market is there, even though it would be an MLC, such drive sounds simply INSANE!

to add a note here,
people who need a fast array can buy 3-4 disks as such, saving themselfs huge costs of buying quarter or at least half of the capacity of SLC's.
heads up lars,
beautiful idea/remark!

You need to get into the SSD design/architecture business & start making us all happy! :D

Quote:

---

Originally Posted by GullLars

I've asked the same question many times. It can be best illustrated by looking at Indilinx Barefoot drives.
You have the 32GB unit that can do roughly 200MB/s read and 100MB/s write, 15K IOPS read and 3K IOPS write, and only has 4 (or 8??) NAND chips on flash 4 channels, and the 256GB unit, wich COULD do 8 times the bandwidth by simply running 8 times the memory chips in parallell, only does 250MB/s read, 180MB/s write, 15K IOPS read, 3K IOPS write.
You can take 8x Barefoot 32GB in RAID-0 off a HBA like LSI 9211 and get roughlly 1400-1500MB/s read, 600-700MB/s write, 120K IOPS read, 24K IOPS write. This makes me think the higher capacity models of Indilinx Barefoot are a complete waste of flash modules, and it's clear the bottleneck is the SSD controller (maybe also the SATA 3Gbps interface for sequential reads on the higher capacities).
You could make a simple SATA 6Gbps SSD with 3x 32GB Barefoot drives and a cheap ROC (RAID-on-Chip) and use internal RAID-0 to get 550MB/s read, 250-300MB/s write, 45K IOPS read, 9K IOPS write, and 96GB capacity.
The same setup with 4x 32GB barefoot would perform 600MB/s read (or whatever the practical limit is), 350-400MB/s write, 60K IOPS read, 12K IOPS write, and have 128GB capacity. Such an SSD would wipe the floor with SandForce 100GB, C300 128GB, and x25-M 160GB, at least with regards to bandwidth and value. Even if you had to use a $100 ROC chip, you could still come in at $500.

Another interresting possibility is 3x x25-V in the same type of setup. ca 550MB/s read, 120-130MB/s write, 90K IOPS read, 30K IOPS write, 120GB capacity, $400 ROC included.

What would be awesome would be a native PCIe SSD with simelar caracteristics as SandForce SF-1500/1200 50/100GB minus the RAISE™, just with 3-4 controllers in internal RAID on the board. Files compressable to to ~20% of original size could be read and written at 2-3GB/s+... Not to mention random write about 90-100K IOPS (4K alligned).

---

Anvil - this is important:

http://www.ocztechnology.com/ssd_too..._Edition_SSDs/

There appears to be only one Firmware on the OCZ website, called V. 1.05
Yet you state on page 1 that you testet with FW 1.0 - can you confirm these are different FW revisions?
I fear they may have imposed the slow 4k performance onto the Vertex LE as well.. or at least onto the 50GB model.

Quote:

---

Originally Posted by jcool

Anvil - this is important:

http://www.ocztechnology.com/ssd_too..._Edition_SSDs/

There appears to be only one Firmware on the OCZ website, called V. 1.05
Yet you state on page 1 that you testet with FW 1.0 - can you confirm these are different FW revisions?
I fear they may have imposed the slow 4k performance onto the Vertex LE as well.. or at least onto the 50GB model.

---

v1.05 firmware retains the original performance on all of the LE drives.

Thanks Praz. Unfortunately the 50GB OCZ's went out of stock here today.. so I gotta wait a few days until I can test/confirm.

Finally I had some time to test the new 1.05 firmware for the Vertex LE.

If anything, it performs equal to or better than 1.00.

iometer 4KB aligned random write
Attachment 103391

Attachment 103392 Attachment 103393

Attachment 103394

Attachment 103396

Crucial new firmware for the C300's is planned for release the 1st week of May.

Not bad for 2R0

Random write 4KB aligned

Attachment 103399

CDM 3.0

Left Random data, to the right all 0 (zeroes)
Attachment 103400 Attachment 103401

Compression is clearly visible using all zeroes.

phew,
197MBps per drive..
that's real massive!
great performance.
the only thing that bugs in these benches is that they don't specify the array, RC or drives..
i'm wondering how much it would scale without aligning, the difference :).

onex,

These are the LE's 100GB with the new firmware, GB X58A-UD7, ICH10R, IRST 9.6. WBC Off, 16KB stripe size for the 2R0 setup.

So 264MB/s seems to be around the max interface speed for the setup you have connected the LEs now, since 0x00 should be extremely compressable. If the drives had come with SATA 6Gbps, it probably would also max that interface for writing 0x00.
Can anyone here with more programming and systems experience than me tell me if it's common to have some percentage of a drive or data written as all zeroes or all ones? (as in pages/clusters, or larger blocks)
If so, making the controller reckognise pages of all zero or all ones and not write them at all but simply list them in the LBA table with a bit (or a few bits) of metadata indicating this would allow for freeing up space, reducing overhead, and always saturating the interface for such chunks of data.
Even more effective if it's a significant percentage, like >1%, having a custom driver reckognizing blocks of zeroes written and simply telling the controller "these LBAs are dev/null, {block list}" would avoid taking up bandwidth for data that doesn't have to be written, and allowing f.ex. empty container files consisting of only zeroes (or ones) to be written near instantly.

wait what, you're saying these drives in RAID-0, for certain types of writes, would max out even sata6g interfaces???

No, not at all. I'm saying if SandForce had made the controller with a SATA 6Gbps interface instead of 3Gbps, it would have maxed the interface anyway for highly compressible data, both reading and writing.

With RAW speeds of about 200-220MB/s read and 120-130MB/s write, data compressible to 1:2 could be read at 400-440MB/s and written at 240-260MB/s, and data compressible to 1:3 could be read at 600MB/s and written at 360-390MB/s...

Anand says in his Agility 2 review that sandforce found installing windows 7 and MS office 2007 physically took up less than half of the original size, meaning those kinds of files would be written above 250MB/s and read above 450MB/s...

The sandforce drives get PCmark scores around 38-40K, with a SATA 6Gbps interface i think they would get over 50K, maybe even over 60K. The limiting factor would be the read IOPS, wich tops out around 30-35K IOPS, and wouldn't get a boost by a faster interface since it seems to be controller computing power bound.

Since it seems the 50GB versions are capable of the same both RAW and compressed speeds as 100GB and 200GB versions, a ROC + 2x SF-1200 in a 2,5" enclosure with SATA/SAS 6Gbps interface could be nice. Sort of like OCZ Apex, G.skill Titan, and OCZ Colossus, only made decently with full NCQ support and not tonnes of accesstime overhead. SF-1200 due to price, and (2x10K=) 20K IOPS sustained random write being "enough". Such a drive would give the same numbers as anvil has posted above, at possibly 1,3-1,5x the price, but on a single port, making it easy to scale to insane bandwidth on LSI 92xx for compressible data (over 4GB/s both read and write).

I've completely forgotten to try these on the LSI 9260.

I'll do that later tonight, as they wouldn't detect on the Marvell 6Gb/s controller they ended up on the ICH on the UD7.

damn it sounds good, shame the $/GB is still a tad too high compared to x25v or x25m :(

Quote:

---

Originally Posted by GullLars

No, not at all. I'm saying if SandForce had made the controller with a SATA 6Gbps interface instead of 3Gbps, it would have maxed the interface anyway for highly compressible data, both reading and writing.

With RAW speeds of about 200-220MB/s read and 120-130MB/s write, data compressible to 1:2 could be read at 400-440MB/s and written at 240-260MB/s, and data compressible to 1:3 could be read at 600MB/s and written at 360-390MB/s...

Anand says in his Agility 2 review that sandforce found installing windows 7 and MS office 2007 physically took up less than half of the original size, meaning those kinds of files would be written above 250MB/s and read above 450MB/s...

The sandforce drives get PCmark scores around 38-40K, with a SATA 6Gbps interface i think they would get over 50K, maybe even over 60K. The limiting factor would be the read IOPS, wich tops out around 30-35K IOPS, and wouldn't get a boost by a faster interface since it seems to be controller computing power bound.

Since it seems the 50GB versions are capable of the same both RAW and compressed speeds as 100GB and 200GB versions, a ROC + 2x SF-1200 in a 2,5" enclosure with SATA/SAS 6Gbps interface could be nice. Sort of like OCZ Apex, G.skill Titan, and OCZ Colossus, only made decently with full NCQ support and not tonnes of accesstime overhead. SF-1200 due to price, and (2x10K=) 20K IOPS sustained random write being "enough". Such a drive would give the same numbers as anvil has posted above, at possibly 1,3-1,5x the price, but on a single port, making it easy to scale to insane bandwidth on LSI 92xx for compressible data (over 4GB/s both read and write).

---

delete.

Gullars,
the only thing that comes in between what u say and reality, is that as an idea, this all seem very nice (though it's hard seeing how a dual SF-1200 SSD with a ROC added to it and redesigned PCB, enclosure etc. will only cost 1.5 times a single SF based SSD) on paper, yet ususally, it's harder to implement and not always gets out "linearly"..
though the idea, is indeed interesting.

another thing which comes up, reading your post, is that the compression is (as far as i understand..), what gives u the 2x times speed, yet actually, you don't get the drive to perform at 270MBps (saturating the protocol)..
the drive itself is manipulating data faster then a normal non-compress-using drive, though the badwidth sup[plied by the SF controller, is not 400MBps full duplex, but rather sending ~200MBps to the CPU and ~400MBps (by your calculation) to the NAND flash chips.

i'm yet to have/see the full view/understanding on that drive so i might be missing here something,
yet from a brief overview, so it seems.

the OWC 50GB SF-1500 based drive costs ~230$, take off the 1500 and place a 1200 on it, take top 40-50$ off,
u got a 190$ drive, double by 2 and add (you said 100$ ROC), so you end up with ~450 (+50 for any overhead),
~500$ for a 100GB drive.., let's say 550.

that's not too bad if it would work as u say (double the ability of a LE 100GB and for a reasonable price add up).

onex,

You wondered about 512B vs 4KB alignment.

2R0 Random write 512B aligned

Attachment 103415

~36' iops 512B aligned
~100' iops 4KB aligned

hmm, thank, no though,
that adds to the info anyhow :).

i was more interested to see a non-aligned test on the 4KB,
though, i don't really understand the difference between aligned and non-aligned...

This *is* the so called non-aligned test.

Block size is still 4KB but using the "old school" 512B sector alignment.

W7 = 4KB
XP = 512B

ow, this is a 4KB test..
141M/36.2K = 4K,

you said the RAID was set on 16KB blocks..
i'm confused with what u'r saying..

No :)

I said that the stripe size was 16KB

Don't confuse stripe size with block size.

so the raid is divided into stripe size, i.e - 16kb, 64, etc..
and there are the NTFS? sectors which are set to 512B on XP and @WIN7 MS has decided to raise it to 4KB for a better alignment..

That is correct.

Using iometer you can set the alignment to any value but sector (512B) or 4KB are the only usable/practical values.

so there's a huge benefit going WIN7 from that aspect!
or rather u can set XP to work 4KB sectors..

anyhow, it has a great effect.

E:
basically, it seems, if you do a 4KB alignment test on a WIN7 (or 4KB block size NTFS drive),
then you should have the SAME results as a non-aligned test..

i can't seem to think of any "normal" usage for doing any non 4KB,512B (or drive's block size) align test, rather if your doing a sequential test for (said) 16KB on an 16KB stripe size array,
you might get an interesting result :hrhr:.

Theres more to it than aligning the drive to a correct offset.

XP doesn't natively support the 4KB sector, all you'd get by aligning the drive is that the drive is aligned to its internal "structure".
XP still won't "think" in 4KB sectors and thats the main difference from Vista, W7 and any other OS with native 4KB support.