Why are my SSD writes so slow?

[SickBeast]

I'm comparing my own benchmarks with those in reviews, and I'm noticing a glaring discrepancy. My writes are much slower than what they're getting.

Here are my Crystal scores:



Now look at this review:

http://aphnetworks.com/reviews/ocz_vertex_2_60gb/4

If you compare my sequential writes, I'm getting ~60mb/sec whereas they're getting around 250mb/sec.

I'm using the default Microsoft AHCI driver on my MSI 770-G45 motherboard if that helps. I tried using the AMD driver but my performance was much worse.

Is AMD's AHCI performance just worse than Intel's? Am I doing something wrong?

TIA

 

[SickBeast]

I just ran the benchmark again with write caching turned off, and it made no difference. The same goes for write cache buffer flushing.

 

[nvidiaintelftw]

Turn on Fill-0 and see what it does. Ussually SSD writes are always low because there more for reading and speed then writing stuff.

 

[dorion]

Is AMD's AHCI performance just worse than Intel's?

Yes.

 

[SickBeast]

Yes.

That's irritating to the point that I might go with Intel next time just because of this. I'm getting less than 1/2 of the performance out of my SSD that I should. It was even worse with the AMD driver installed.

I would be interested to see some cross platform SSD benchmarks comparing AMD and Intel. This is a big deal IMO.

 

[SickBeast]

Do you guys know of a good PCI-E SATA card that will do well with AHCI?

 

[SickBeast]

Turn on Fill-0 and see what it does. Ussually SSD writes are always low because there more for reading and speed then writing stuff.

I cringe at the thought of having to reinstall everything.

Maybe I'll create an image and try it. Will it really do anything though?

 

[kamikazekyle]

Confirming I get the same thing. Bit more write, bit less read. This is on an AMD 870 chipset using a Vertex 2. Though I had this SSD on an nvidia 680i mobo before hand. My old 7200 RPM RAID0 is posting twice the write performance on sequential writes.

EDIT: This is using the AMD 1.2.0.164 AHCI driver.

 

[SickBeast]

Confirming I get the same thing. Bit more write, bit less read. This is on an AMD 870 chipset using a Vertex 2. Though I had this SSD on an nvidia 680i mobo before hand. My old 7200 RPM RAID0 is posting twice the write performance on sequential writes.

This is completely unacceptable and I will not be buying anything from AMD in the future if this persists.

Are those PCI-E Highpoint SATA3 controllers any good? $40 + $10 shipping is a lot to pay. I'll probably just upgrade my entire platform.

 

[SickBeast]

EDIT: This is using the AMD 1.2.0.164 AHCI driver.

You should go into device manager and roll back your driver to the Microsoft one. It's way faster. Still not as fast as an Intel setup would be, though.

 

[kamikazekyle]

Ok, to update some more. Uninstalling the ACHI driver and using the MS one yielded the same speeds as the .164 driver. The latest ACHI driver from AMD decreased performance to 55 MB/s sequential from 64ish.

*However*, changing the test sequence (File > Test Data) to 0-Fill like nvidiaintelftw mentioned saw my Read speeds hit 264 and my write hit 238 on the same test. 1-fills were a smidgen higher (within test variance percentage) In that review you linked, it doesn't mention what test pattern they used on CrystalMark. When using 0 or 1-fill, I get similar to their results. I'd suggest trying another bench and seeing how that performs.

Can't do any more testing right now since I have to go to bed in half an hour. If my 680i system was still here and not at my girlfriends and I had a few hours to blow, I could compare the two off fresh installs on two completely different architectures. Buuuut, that's 120 miles away so that'll have to wait

EDIT: When comparing load/save times for Minecraft a while ago -- heavily random based writes and reads -- with a friend using all Intel gear and the same drive, we got very similar performance. There are some variables introduced with different processors and the fact we weren't using an identical save file, but they were well within each other's proverbial ballpark.

 

[SickBeast]

Oh ok, I didn't understand what he meant by 0-fill. Now my speeds are much, much better! Thanks for that!



I'm happy now. My drive is performing as it should.

 

[Emulex]

basically you are allowing the ssd to cheat the benchmarks since it has compression so it makes you feel better. most binaries/data/etc are already compressed so the real numbers you posted first are more typical but if you download a bunch of files filled with zeroes you get that faster speed it's not very advanced compression compared to 7zip

 

[frostedflakes]

It's due to SandForce's DuraWrite system, which tries to reduce the amount of data written to the SSD. In addition to reducing write amplification, this also allows for higher performance by increasing the effective transfer rates. In the best case scenario (highly compressible data), drive speeds will approach the 285/275 that most manufacturers claim in their specs for SandForce drives. In the worst case scenario (incompressible data) speeds will be closer to what you saw in your first CrystalDiskMark. In the real world, you'll probably see performance somewhere in the middle of those two. It depends on what you write to the drive, though. If you write a lot of music, movies, and other compressed files to the SSD, DuraWrite probably isn't going to be able to do much (but I'd imagine for most of us, files like that get saved to an HDD and not our SSD, so it's kind of a moot point IMO). However, for writing to the swap file and other writes that SSDs typically receive as an OS disk, DuraWrite seems to be pretty effective at compressing data as SandForce claims 0.5x write amplification with their controllers and Anand actually measured write amplification of their drives and saw real-world results pretty close to this. Most of the drives had 0.6x write amplification, which is pretty impressive. Means that the controller was able to compress the writes it receives by about 40% or so on average.

Thankfully one of the unwritten policies at AnandTech is to actually use anything we recommend. If we're going to suggest you spend your money on something, we're going to use it ourselves. Not in testbeds, but in primary systems. Within the company we have 5 SandForce drives deployed in real, every day systems. The longest of which has been running, without TRIM, for the past eight months at between 90 and 100% of its capacity.

SandForce, like some other vendors, expose a method of actually measuring write amplification and remaining p/e cycles on their drives. Unfortunately the method of doing so for SandForce is undocumented and under strict NDA. I wish I could share how it's done, but all I'm allowed to share are the results.

Remember that write amplification is the ratio of NAND writes to host writes. On all non-SF architectures that number should be greater than 1 (e.g. you go to write 4KB but you end up writing 128KB). Due to SF's real time compression/dedupe engine, it's possible for SF drives to have write amplification below 1.

So how did our drives fare?

The worst write amplification we saw was around 0.6x. Actually, most of the drives we've deployed in house came in at 0.6x. In this particular drive the user (who happened to be me) wrote 1900GB to the drive (roughly 7.7GB per day over 8 months) and the SF-1200 controller in turn threw away 800GB and only wrote 1100GB to the flash. This includes garbage collection and all of the internal management stuff the controller does.

 

[kamikazekyle]

basically you are allowing the ssd to cheat the benchmarks since it has compression so it makes you feel better. most binaries/data/etc are already compressed so the real numbers you posted first are more typical but if you download a bunch of files filled with zeroes you get that faster speed it's not very advanced compression compared to 7zip

basically you are allowing the ssd to cheat the benchmarks since it has compression so it makes you feel better. most binaries/data/etc are already compressed so the real numbers you posted first are more typical but if you download a bunch of files filled with zeroes you get that faster speed it's not very advanced compression compared to 7zip

Just coming back to say this And my hard drive raid configuration is running on the same achi drivers as my SSD. I'm using Windows software striping vice hardware or psuedo hardware raid. So it's not really the drivers all that much; just the nature of the beast. I think anandtechs benches are pretty solid foundations for actual performance characteristics.

It's due to SandForce's DuraWrite system, which tries to reduce the amount of data written to the SSD. In addition to reducing write amplification, this also allows for higher performance by increasing the effective transfer rates. In the best case scenario (highly compressible data), drive speeds will approach the 285/275 that most manufacturers claim in their specs for SandForce drives. In the worst case scenario (incompressible data) speeds will be closer to what you saw in your first CrystalDiskMark. In the real world, you'll probably see performance somewhere in the middle of those two. It depends on what you write to the drive, though. If you write a lot of music, movies, and other compressed files to the SSD, DuraWrite probably isn't going to be able to do much (but I'd imagine for most of us, files like that get saved to an HDD and not our SSD, so it's kind of a moot point IMO). However, for writing to the swap file and other writes that SSDs typically receive as an OS disk, DuraWrite seems to be pretty effective at compressing data as SandForce claims 0.5x write amplification with their controllers and Anand actually measured write amplification of their drives and saw real-world results pretty close to this. Most of the drives had 0.6x write amplification, which is pretty impressive. Means that the controller was able to compress the writes it receives by about 40% or so on average.

Tho frosted says it far better than I

 

[groberts101]

yep. Frosted flakes has studied his "Sandforce facts". Don't know how many times I've written almost the exact same thing over at OCZ.

One's a worst case(AS SSD/CDM3 = incompressible) and the other best case(ATTO/others = compressible). These drives float in between and bandy about throughoutn the entire logged on session dependant on the average file types used, which is why they are so good in an OS as that data is small random and typically more easily compressed.

 

[Emulex]

osx compresses swap and hibernate file. not sure if windows does. you'd think so since you could use your spare cores to decompress faster than your disk can move data if its compressable. again 1 core (let's say everyone has a 2-core 3.0ghz core2duo effective cpu) can decompress far faster than anything on the sandforce controller chip. i'd suspect its doing RLE and deduplication more so than LZW - you could test this by creating complex patterns. 7zip would detect them and compress and a less intelligent engine would not.

for benchmark sake - take the worst case. It's like people that take 15-18% and add it to their dyno when they run their car because they think they can estimate losses to convert wheel horsepower to brake horsepower. This is not possible and is just an ego booster.

But unless you are trying to stretch your e-peen you'll realize this is still fast and the intel drive is about just as fast so whoop-de-doo. enjoy it! there is more to life than benchmarks. In the car world we call folks Dyno-queens who get too uptight over numbers.

 

[groberts101]

I don't run benchmarks to play fight. I use them for configging and squeezing the last bit of performance out of a system before SE/reimage and one final set up. Most are just the opposite.

And talking about file compression algorithms in relation to how the Sandforce operates is just stabbing in the dark. Unless you're a Sandforce engineer, in which case I'm all ears.

You like Intel.. I "get it". I like Sandforce.. and you should "get that" by now too.

Some do notice that last little bit of power and are perfectly content driving 6 cylinders. Others aren't and want a V8 even though we're all supposed to be driving the same speed limit. Well... "I can't drive 55". LOL

 

[nvidiaintelftw]

run the ATTO benchmark. its better for the drive. Crystal Disk writes information to the drive which dimishes the life out of it

 

[frostedflakes]

osx compresses swap and hibernate file. not sure if windows does. you'd think so since you could use your spare cores to decompress faster than your disk can move data if its compressable. again 1 core (let's say everyone has a 2-core 3.0ghz core2duo effective cpu) can decompress far faster than anything on the sandforce controller chip. i'd suspect its doing RLE and deduplication more so than LZW - you could test this by creating complex patterns. 7zip would detect them and compress and a less intelligent engine would not.

for benchmark sake - take the worst case. It's like people that take 15-18% and add it to their dyno when they run their car because they think they can estimate losses to convert wheel horsepower to brake horsepower. This is not possible and is just an ego booster.

But unless you are trying to stretch your e-peen you'll realize this is still fast and the intel drive is about just as fast so whoop-de-doo. enjoy it! there is more to life than benchmarks. In the car world we call folks Dyno-queens who get too uptight over numbers.

I believe the SandForce SSD Anand mentioned in the above quote that was running without TRIM is on OS X. So if it does do any additional compression, it doesn't seem to significantly impact the performance of DuraWrite, as the write amplification was still about 0.6 as on the other four drives sampled.