Vertex LE vs Crucial C300

[IanB]

Hmmmm. This is going to be interesting....

Just for chuckles, I checked the scan.co.uk website to see how these things are pricing in the UK. http://www.scan.co.uk/Shop/Computer-...%29-80GB-500GB

Taking the advertised speeds as a guide, there's a fascinating lineup right now around the £300 price point where the battle between last year's tech and this year's will be fought:

128GB Corsair Nova Series 64MB DDR2, Read 270MB/s, Write 195MB/s, in stock @ £293
128GB Crucial RealSSD C300 SATA 6Gb/s, Read 355MB/s, Write 140MB/s, in stock @ £310
100GB Corsair Force Series F100 SandForce controller, Read 285MB/s, Write 275MB/s, pre-order @ £321
100GB OCZ Technology Vertex 2 Sandforce Controller, Read 285MB/s, Write 275MB/s, pre-order @ £351
160GB Intel SSD Gen 2, Read 250MB/s, Write 70MB/s, in stock @ £351

I'm not sure the OCZ/Corsair F100 at just over half the size of the 160GB Intel can really justify that price even for that speed - can there be THAT big a market of extreme enthusiasts out there with money to waste on absolute performance over capacity? Especially when the write speeds are the least important factor for most people's day-to-day usage. The Corsair Nova or Crucial C300 @ 128GB will surely give the Intel 160GB (still with the crippled write speed) a run for its money though at those prices. Even I'm tempted, and I've been loving the x25-v.

Comparing these few drives properly would be an absolutely cracking head-to-head benchmark review.

[Biker]

Brilliant testing!

Thanks for sharing

[Computurd]

my question is....where in the world is Jetstream?? idilinx next gen controller, rumored to be 500 read/500 write. it is late but last i heard it was still in the works...i would love to hear whats going on with that.

[GullLars]

I've mailed them and requested non-binding ETA, as well as any non-binding performance estimate (more than just seq) they are willing to share. I sent the mail in the beginning of the week, and have not yet got any response.
My mail also included questions of capacity points, and estimated performance and pricing of capacity points (again non-binding and whatever they want to share).
I mentioned a strategic advantage of sharing some of this info at this time, since many people are considering SandForce, C300, and RAIDs of low-capacity SSDs around this time, and if JetStream has nice numbers and ETA in Q2 many people may hold out for it.

[Computurd]

excellent work, there hasnt been any info from the iddilinx camp for a while now...

[GullLars]

It would be awesome if they made JetStream start at 32GB with 4x 8GB chips of ONFI 2.1 NAND with 200MB/s read pr chip (maybe a bit high? But 166-200 is the spec). Ofc, the last chip wouldn't help on SATA 6Gbps, but it would secure that the read bandwidth would be saturated. Write bandwidth could then scale linearly with the capacity, like 100MB/s @ 32GB, 200MB/s @ 64GB, 400MB/s @ 128GB, and 600MB/s (or whatever saturated is on any given SATA 6Gbps controller) for 256GB.
Even if it was made with only 4 flash-channels (for easy making of controller architecture and NCQ implementation), 5000(+?) random read IOPS pr channel and random write IOPS 10K IOPS @ 32GB scaling close ot linearly with size.
Another posibility could be 8x 4GB chips (single die) with 100MB/s read pr chip for higher IOPS.

Anyways, if they made a low-capacity SSD (32/64GB) with 600MB/s read, OK IOPS (minimum 20-30K read, 10K write), and OK write bandwidth (60+ for 32GB), i would totally buy a LSI 9211 and go 4x 32GB JetStream, or possibly 64GB (if lowest capacity).

[IanB]

Checking prices again, lower down the scale I see the 50GB OCZ Vertex 2 Sandforce drive is listed for pre-order @ £176 while you can get a full 80GB of Intel V2 goodness for £188, where the only difference is really the write speed.

What on earth is OCZ thinking? This isn't SLC! For the more cost-conscious low-end market, at that capacity/price it's going to be an extremely hard sell against the known reliable Intel brand leader. Or, looking the other way, against the x25-v which is only marginally smaller for half the price.

[Computurd]

@gullars..if you need a 9211 i know someone selling one

[GullLars]

In norway?

Anyways, i think i will hold off buying another RAID controller untill Areca 1880 is out, and there is more info on LSI's dual core megaRAID card (wich was announced to be sampling to OEMs in december).

[Computurd]

LOL forgot about the norway part. i am also interested in the lsi dualcore megaraid but that wont be a viable solution until there is a pci-e 3.0 mobo out....i know i know sandy bridge is coming!

[onex]

Steve,

Here's my observations on the LE regarding sequential writes.

Files used:
-iometer test files 10GB
-Virtual Machine 21GB
-Images (jpg, nef) 11GB

Attachment 102954

I added the C300 for comparison. (139GB of VM's)

The author of AS SSD confirmed that the data used in his Benchmark is hard to compress, and so both the random and sequential read/write throughput reported by AS SSD should be worst case.
Based on this I'd say the Vertex is a solid performer whichever way you look at it, but performance will vary.

am i missing something or did u manage reading out drive performance on the fly ?
how did you do that ?

anyway, don't know really, why, yet, i'm much more impressed with the LE's write capabilities ,
up to ~260MBps?
that seems insane, isn't it ?
or is the charts ain't right..?

E:
so this is AS-SSD right?
where did you bring these img or VM files?
AS-SSD shows only ISO, game & program files..

[GullLars]

With a raw write-speed of ca 140MB/s, vertex LE can do 260-270MB/s write on files that are compressable to about half their original size.
If they had made it with a 6Gbps interface and powerfull enough controller to handle it, files that are compressable to 1/3 or 1/4 of original size could be written at 400-550MB/s, and probably be read back at the same speed or higher since the compression would speed up both read and write.

Compression is a really interresting feature for SSDs. Combined with the powerfull write-combining sandforce uses to get random write speeds (4K alligned...) equal to raw write speed, it's a brilliant piece of engineering.
RAISE™ doesn't hurt either, but is a bit overkill for consumers. It's almost comparable to Fusion-IO's engineering skills, just towards a different market. Too bad the prices are too high compared to capacity and performance at this time. RAIDs of low-capacity SSDs bring better value where it is possible to RAID.

EDIT: TeraCopy lets you read out copy speed on-the-fly. He probably copied to his SSD RAID on LSI 9260.

[Anvil]

onex,

The test didn't include AS SSD, I only mentioned AS SSD as a sidenote as it correlates to the throughput I measured using compressed files.

The test involved copying my own set of files onto the LE from a capable source and throughput was measured, as such this is a realistic test and not a synthetic benchmark.

[onex]

gullars -

so what u'r saying actually, is that the vertex LE is using a HW algorithm, which compressed every piece of data which is going through it as a normal process, if u'r copying a 1-GB file from an external HDD to u'r SSD,
it should get much smaller on the SSD (with relation to the file format),
this operation, allows the SSD to gather speed, the latency created by the HW algorithm is lees effective then the actual speed increase.
is that right ?

EDIT: TeraCopy lets you read out copy speed on-the-fly. He probably copied to his SSD RAID on LSI 9260.

oh, grats, i'll have it looked.

and tnx anvil .

[GullLars]

I'm not sure what you're trying to say here...

if u'r copying a 1-GB file from an external HDD to u'r SSD,
it should get much smaller on the SSD (with relation to the file format),
this operation, allows the SSD to gather speed, the latency created by the HW algorithm is lees effective then the actual speed increase.

The SSD compresses all data on-the-fly internally, i'm not sure if it checks if it's compressed first, or makes a compressed copy and compares it to the original to see wich is smaller.
The added latency from compressing and decompressing is smaller than the reduction of time it takes to read/write the compressed data, so you get an overall speedup. How big a speedup depends on the data, more specifically how compressable it is.

[SteveRo]

Is compression on all sandforce drives or just some?

[onex]

I'm not sure what you're trying to say here...

i was saying, when u copy a f. ex. 1GB file from a HDD to a SF based SSD, considerating the compression (20-30% (depends on the file format), u should see a considerable reduce in size.
data is on the drive, now, it is being compressed and decompressed for some reason,
the controller is doing all the CODEC operation, yet why is it doing that?
what is the procedure?
do u understand?
it is probably doing that to save space, isn't it?
it copies a 4MB file from on block to the other, does the OS see it?
it changes a few bytes and it rewrite it in a different location, it decompress it, loading it into memory, changes it and compresses it again, copying it to it's new location.

[alfaunits]

I don't think it copies data internally between blocks, that would waste write cycles.
(frankly, I don't understand what onex wanted to say either )

I don't think you should take JPG images as sequential write speeds, as there are more than one, probably small ones. The file system needs to handle such a case differently from a write to a single file.

[alfaunits]

BTW, is the C300 bug that some people had fixed or not?

[GullLars]

I'm not exactly sure of HOW it's implemented since sandforce uses no external RAM chips in it's SSD. I will speculate it has a rather large internal cache in wich it holds a block of incomming data, makes a compressed version, compares, and discards the biggest before doing streaming writes to pre-erased flash blocks.

I will try to elaborate a bit with text, and edit this post with a basic illustration made in paint a few minutes later.
So you have f.ex. a 5MB excell spreadsheet stored on a HDD. This document is compressable to let's say 20% of original size to take an arbitrary number.
You decide to copy the 5MB spreadsheet to your SF-1200/1500 SSD, and to the copy command. The file is read as 5MB from the HDD, transfered to the SSD with the HDD's speed as the limiting factor, the file enters the SSD controller, gets compressed to 1MB, and written to 1MB of flash. The OS still sees the file as being 5MB and taking of 5MB worth of LBAs. Since the SSD only used 1MB worth of physical blocks, it can erase 4MB of obsolete (dirty) data, and use this as dynamic spare area for GC and wear-leveling. Sort of the same way as SSDs with TRIM can use free space as dynamic spare area.
Since SandForce supports TRIM, it can use both, and possibly get 30-50%+ physical spare area even though holding 80-100% of it's specified formatted capacity with valid data.
Already compressed or encrypted data cannot be compressed by the SSD, these files will be unaffected by the SSDs compression algorithms, and will reflect the RAW speed of the SSD (the physical NAND speed).
Now, to continue the example with the 5MB spreadsheet. If you later want to open it from the SSD, reading it will trigger 1MB of data to be read from the flash, and then de-compressed in the controller, and sent to RAM. Let's say it takes 5ms to read the 1MB from the flash, this would translate to 200MB/s read speed, but since it gets de-compressed to 5x that size in the controller, you will saturate the SATA interface at ca 280-290MB/s for 17ms = 5MB. If the SSD had used a SATA 6Gbps interface, it COULD have read the file from flash in 5ms, and transfered it at 550-600MB/s for 8,5-9ms (if the controller could handle that fast de-compression).

To continue the example, if you then were to save the 5MB spreadsheet back to the SSD after editing it, it can be saved to flash at 140MB/s (raw write speed) times compression, wich is 5x (20% of original size) = 700MB/s, but that's much higher than the interface speed, so you end up saturating the interface instead at ca 270-280MB/s for 17ms. If the SSD had been made with SATA 6Gbps interface, it could have been written at 550-600MB/s since the compression is good enough, ofc if the controller could compress at that speed.

Another added benefit from this compression is that you will sometimes saturate the interface, whitout maxing the flash performance, so the SSD can actually do GC in the background whitout affecting performance at all, and because a lot of the data on the drive will be compressed by some ammount, the big spare area will allow more efficient GC. Combine compression with streaming random writes sequentially to pre-erased blocks and just re-organize the LBA abstaction map, and a large effective spare area to allow efficient GC, you have a recipe for extremely low write amplification. Postulating average compression ratio of 10-20% (80-90% of original size) or more, you can get a write-amplification below 1x.
The sandforce SSDs are a great piece of engineering, qualifying for the big league with Fusion-IO, Violin, TMS, etc. engineering wise.

EDIT: added picture

[Anvil]

I've just upgraded one of my LE drives to 1.05, it's supposed to perform just as fast as the original firmware.
Upgrade tool is user friendly, one can update the firmware from W7, AHCI is required.

BTW, Anand has been called to a meeting with SandForce
Link

@alfaunits,
What bug?
My drive has been performing admirably well in my laptop, no issues.
Crucial made a statement that an update was due mid-April, nothing so far though.

[alfaunits]

The bug mentioned on Anand regarding C300 bricking on some computers.

[Anvil]

Oh, that bug

I don't think it bricks more than any other new gen drive, I can't recall any brand of SSD that's not been bricked yet.

Both the SandForce and the C300 controllers are new on the market, a few more FW updates are probably needed on both controllers.
Some drives will still brick, it's just the way it is.

[onex]

you have raised few issues here that should be cleared out before going any further,
the SATA 2 protocol is being saturated at ~300MBps minus a little vague overhead,
at it's theoretical capability, it is able to transfer signal up to 300MBps, yet it is losing some of it's capacity do to currently a bit irrelevant factors.
what is happening inside the SATA protocol is (or should) be the same as what is happening inside the DRAM protocol,
u got a signaling rate which is limiting the device bandwidth, well so it seems.
the SATA controllers should be well capable of delivering a much higher throughput then ~300MBps,
memory controllers has showed that with speed up to many GHz (such as AMD's platforms which can sustain up to 40GHz of mem bandwidth (or i'm mistaken, i'm unsure if it is really capable of such bandwidth and how it really operate it)
yet anyhow, controllers and CPU's are much more capable then 300MBps of streaming data.
the controller optimal speed is unknown, we only know that ONFI 2.1 is capable of delivering 166-200MBps.
now one question laying, is whether each memory chip is capable of delivering up to 200MBps of bandwidth, so generally speaking, a 10 channel X-25M raided memory cell matrix, or any other onfi 2.1 device, should be capable of delivering up to 2GBps.
and well, that somehow sounds unreasonable, and it is bugging talking about these standards and specifications, with half the data...
nothing profound can be found like this.


adder -
lol,
ran into some interesting thing,
when u convert -let's say- 15KB into MB, it doesn't equal 15MB..
what we normally miss here, is the fact that 15KB equals of course 15,360,000 Bytes, yet a MB is 1024*1024 = 1,048,576, so deviding the 15.3KKB isn't going to give u the exact bandwidth,
what u do then is dividing the 15,300,000 by an ACTUAL MB, which equals 14.6MB.. .

anyway's, back to the issue:
been looking for some info on the ONFI standart and came up with some interesting finding,
u can see MLC vs SLC market share on 2006 in this pdf by Micron,
it's a very informative document...

if u'll go through this PDF, u can see that NAND flash at 16bit IOS can reach speeds of up to 40MBps,
i'm really wondering what are the cavities which sets an 10 MLC chip array ~3 years later to operate only (if it can be said) at speeds up to ~250MBps.
this isn't the protocol of course,
it triggers the question, of what did crucial did with they're C300, whether this is all about the flash chips, or more widely,
WTH is going on .

[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).