• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

4 SSDs - Performance Results are Backwards?

Moogoos

Limp Gawd
Joined
Apr 30, 2012
Messages
334
I have 4 drives in 4 separate machines. 3 ubuntu ivy bridge VM hosts and a laptop. Here are the results.

This is so ass backwards:

MacBook Pro with Samsung Pro 840 512GB:
dd if=/dev/zero of=/tmp/test.img bs=1000000000 count=20
20000000000 bytes transferred in 153.998735 secs (129871197 bytes/sec)

Ubuntu 12 Crucial M4 256GB z77
dd if=/dev/zero of=/tmp/test.img bs=1G count=20
21474836480 bytes (21 GB) copied, 70.6452 s, 304 MB/s

Ubuntu 12 with Samsung 840 250GB not Pro H77
dd if=/dev/zero of=/tmp/test.img bs=1G count=20
21 GB) copied, 73.1345 s, 294 MB/s

Ubuntu 12 OCZ Solid-3 120GB H67
dd if=/dev/zero of=/tmp/test.img bs=1G count=20
(21 GB) copied, 37.6239 s, 571 MB/s

All on SataIII port
AHCI
16GB RAM or more
i73770 on Ubuntu Machines
All independent machines

It should be the other way around.

So confused on why……
 
So I guess the 840 non-pro and M4 are to spec:

Samsung - Sequential Write Speed: Up to 240MB/s

Crucial - 260 MB/sec sequential writes (at 6 Gb/sec)

Solid-3 - Up to 450 MB/s (SATA 6Gbps)

Blew me away that the newer drives were slower than the first SSD I ever bought. Now I need to figure out what's up with my laptop pro drive.
 
Blew me away that the newer drives were slower than the first SSD I ever bought.

They are not really.

Remember that the solid is a sandforce drive that compresses data before writing.

/dev/zero will compress to next to nothing so for that test you are not really writing data to the NAND. You probably wrote a single block to the nand. Repeat the test with a real file and the results will be different.
 
Last edited:
This benchmark is not useful. The compression issue is just the tip of the iceberg.

The write speed on an SSD that is already in use depends on many factors including how full the filesystem is and how good a job has been done on trim.

And the last chunk of your written file is still in RAM by the time that dd returns to the shell. That amount is highly variable.
 
This benchmark is not useful. The compression issue is just the tip of the iceberg.

The write speed on an SSD that is already in use depends on many factors including how full the filesystem is and how good a job has been done on trim.

And the last chunk of your written file is still in RAM by the time that dd returns to the shell. That amount is highly variable.

All the systems are the same; same OS, same test, pretty much the same all around except for my MacBook. The faster drive was actually more filled than the others being so much smaller. All OS variables again, the same. I don't even know if trim is enabled on Ubuntu.

They are not really.

Remember that the solid is a sandforce drive that compresses data before writing.

/dev/zero will compress to next to nothing so for that test you are not really writing data to the NAND. You probably wrote a single block to the nand. Repeat the test with a real file and the results will be different.

Ok will try some more tests today in straight copy but the specs still state that write times are faster for the older SSD.
 
Last edited:
Ok will try some more tests today in straight copy but the specs still state that write times are faster for the older SSD.

Try a compressed file on the Sandforce drive.
 
Code:
(while : ; do cat somebigfile.gz ; done) | time dd of=/dev/sda
time sync

The time for the sync should be added to the benchmark as it writes down contents from your benchmark.
 
Compressing a folder onto the drive that has a lot of objects or copying a gz?

A single compressed file like a 10GB gz would be great.

Edit: uOpt gave a better answer than me..
 
Code:
(while : ; do cat somebigfile.gz ; done) | time dd of=/dev/sda
time sync

The time for the sync should be added to the benchmark as it writes down contents from your benchmark.

I don't want to write over my sda device. That's my drive. I sorta need it. I can only test copying or creating images/files.
 
I don't want to write over my sda device. That's my drive. I sorta need it. I can only test copying or creating images/files.

You use the same dd parameter that you used to before, except for "if=" which you omit.
 
Back
Top