I have an 512 GB Samsung 840 Pro SSD on a Linux machine (CentOS 6.4, 64-bit) with an i7 CPU. The SSD drive is connected to a 6 Gb/sec SATA connector on the system board. The entire SSD has one large 480 GB ext4 partition. Tom's Hardware reports this SSD as giving 480 MB/sec for sequential writes. However, when I fill the disk with repeated calls to this dd command:
I only see about 240 MB/sec. If I run fstrim in the entire partition, and rerun the test, I only see 240 MB/sec. If I delete the files, and then DON'T run fstrim, and rerun the test, I still only see 240 MB/sec. I tried other block sizes as well. However, I can't get the write speed to budge from 240 MB/sec.

So it seems that either fstrim isn't working for me, or maybe this isn't the correct way to perform sequential write benchmarks, or maybe the SSD isn't somehow configured correctly, or fstrim isn't configured properly, or maybe Linux doesn't support SSDs correctly? Does anyone know why I'm not seeing faster write speeds, and what can I do to see the faster write speeds?

Try:

I'm not sure what that was supposed to do, but I tried 'conv=fdatasync' and write speeds were about 190 megabytes/second.

From the dd man page:
"fdatasync: physically write output file data before finishing"
In other words it should show the actual data throughput without the effect of caching to RAM. You might find this interesting:
https://wiki.archlinux.org/index.php/SSD_Benchmarking

Regards,
Stefan

1 members found this post helpful.

I would also suggest using something larger than 1K for a buffer. Try 4k/8k/16k.

1k is rather bad for the I/O scheduling and DMA (lots of extra overhead).

SSD speed can be wildly contrived. For instance, the hdparm -T command might read 2,000 MB/s. But that's from the drive buffer cache, so it's not really fair. Making a 50 GB file of zeroes with dd is better, but dd uses four buffers. I believe the source data is read into the first buffer, a second buffer verifies the data with the original read bufer, after which data is written to the target and then read into the third buffer, which is compared to the first buffer for verification. If all that checks out right, the dd program moves on the next block of data.

To say the least, that is just going to be slow. It's not like an office application writing to the disk. From what I know, about 250 MB/s is a good realistic rate for such a drive as yours.

How much speed do you get when used hdparm?
Also try this links:
How to maximise SSD performance with Linux
How to Tweak Your SSD in Ubuntu for Better Performance

After Edit: You can also try what interface its using (1.5/3/6). For example my SATA hdd uses 1.5 Gb/s and 3 Gb/s. In your case it should also show 6 Gb/s. If not, check sata cable. Cant say it works for SSD though.

1 members found this post helpful.

How much speed do you get when used hdparm?
Also try this links:
How to maximise SSD performance with Linux
How to Tweak Your SSD in Ubuntu for Better Performance

After Edit: You can also try what interface its using (1.5/3/6). For example my SATA hdd uses 1.5 Gb/s and 3 Gb/s. In your case it should also show 6 Gb/s. If not, check sata cable. Cant say it works for SSD though.

1 members found this post helpful.

I tried the following, and hdparm reported read speeds around 307 MB/s:
I also tried this:
This is interesting. The SSD is connected to the SATA 6.0 Gb/s connector on the system board. Why does hdparm report 3.0 Gb/s? You said to check the cable. The SSD did not come with a SATA cable, so I used whatever I had handy. I see on newegg that some SATA Cables are listed as 6.0 Gb/s. Are they really different then other cables?

Actually i was suggesting to check if there are different SATA2 and SATA3 interface, and that have you plugged to correct SATA3 interface. But a quick google cleared that there should not be difference (bet 3 & 6), unless the sata cable is cheap one. SATA 3Gb/s vs. 6Gb/s Cable Performance

Anyway, these are the some areas you have to check for problems:

• Mother Board interface (SATA III)
• BIOS (IF possible update bios)
• Write Cache (Some ssd comes with cache, if its so then disabling write cache greatly improves write speed)
• SATA cable

I'm using the SATA III connection on the system board. I checked for BIOS updates, there are some, but none of them address the SATA III. The SATA cable shouldn't matter, according to the article you referenced. Not sure what else to check. But Tom's Hardware clearly achieved about twice as high write (and read) bandwidth on this exact drive under windows as I am under linux. So something is definitely wrong.

The 3.0 Gb/s output from hdparm must be a clue.

Not all SATA controllers are created equal. Many of the addon SATA controllers found on motherobrds use junk marvel (etc.) controllers.....which often run very badly even with windows. With linux they run far worse. Even if labeled 'SATA6' or 'SATAIII' can be limited to SATAII as well, I've seen reports of that even with windows.

At least some of them do not support TRIM either.

What motherboard are you using?

You might want to write a short script that does the dd with a timestamp at the start and timestamp at the end and calculate the write speed yourself. It could just be reporting an incorrect value. Also bear in mind that writing files to a filesystem has more overhead than writing data to a whole disk.

Try this, one guy told that by changing to AHCI, it improved speed:

From:
[SOLVED] Samsung 840 Pro-- very slow in new build. Why?

I'm using an Asus Sabertooth X58. It has a Marvell SATA III controller. When I boot, the boot message lists that Marvell SATA controller and it lists it as 6 Gb/sec.

Yes, I did that originally. That is where the 240 MB/sec numbers come from.

I did something similar. In the BIOS, I then changed the Marvell controller from IDE to AHCI. It didn't make any difference in the speed tests.

Take a look at this links

Solid-State Disk Deployment Guidelines
SSD performance tips for RHEL6 and Fedora