Linux SSD vs HDD performance - minimal SSD advantage at best?

[dagoldman]

I recently posted a similar message to the storage forum, did not get any replies. Here is a modified version. I am hoping some linux experts can either confirm my findings, or suggest what I am missing.

************** Introduction:

I recently built a system:

Supermicro X10SAE-O ATX DDR3 1600 LGA 1150 Motherboard
CPU: Intel Core i3-4130 LGA 1150
RAM: Kingston KVR1333D3E9S/4G 4GB 1333MHz DDR3 ECC CL9 (2)
HDD: WD WD10EZEX 1 TB, 3.5 Inch, 7200 RPM, SATA 6, 64 MB Cache (boot disk)
SSD: Samsung 840 EVO-Series 250GB SATA III SSD (not boot disk)
PSU: Corsair CX Series 430 Watt Power Supply CX430M
OS: Ubuntu Linux 12.10
SSD fstab: /dev/sdb /home ext4 defaults,errors=remount-ro,noatime,nodiratime 0 1

Case: Cooler Master FOR-500-KKN1 Force 500
DVD-RW: Asus DRW-24B1ST 24X (Black) (x 2)

http://www.pcworld.com/article/2048120/benchmarks-dont-... shows a typical glowing report about how great an SSD is. I was intrigued by getting the SSD, after reading such glowing reports. But I figured I should do some tests to compare how much faster it was than the HDD.

************* Methods:

I did a comparison on three real-world, time-consuming tasks with a lot of disk IO, that I carry out pretty often as part of my software development. These are the whole reason I got the SSD, the SSD would be of no use if it did not speed up these tasks. First I did the task on the hard disk drive (HDD). Then I did the exact same task, with exact same files but on the solid state disk (SSD). I measured how many seconds ("real" result from Unix time command) the task took to run.

The details of the tasks don't exactly matter, but here they are:

Task A) Repeatedly compile some 300,000 lines of source code to make an executable for running on the desktop. Each compilation produces one version of the Vitalnet data analysis software. For example, one version analyzes Texas birth data, one version analyzes California death data, another analyzes Iowa cancer data, etc. There are some 20 versions created, so some 20 compiles. It compiles the same C source files each time, with different gcc defines to produce different result.

Task B) Convert some 250 web pages needed for ehdp.com web site. The web pages are in a "source code" format, and get converted to the final .htm format. Uses shell scripts and lots of temporary files. Again, same files get repeatedly converted, with different defines.

Task C) Convert help files for the Vitalnet desktop versions. Each desktop version has about 50 help files, so about 1000 help files are converted. Uses shell scripts and lots of temporary files.

************ Results:

HDD SSD Task
-------------------------------------------------
134 134 A) compile source code
19 19 B) convert web pages
100 100 C) convert help files
-------------------------------------------------

All the tasks are using all the cores of the i3-4130 cpu. I use "make -j 4" and xjobs to accomplish that, and double-checked with top (1) command that all cores are working equally.

*********** Discussion:

So with these real-world tasks the SSD does not help any on the linux computer, at least with this configuration and tasks. The results are EXACTLY the same, although I am sure the first number is for the HDD and the second for the SSD.

I might have guessed this before. I work a lot with large data files, and had done other tests years ago about disk IO on linux. The linux OS seems very fast to read the disk, can read very large files in virtually no time, based on tests I did before. The first time is fast, but the effect really shows up once a file has been read. It caches read files to RAM, so the second time the file is read, it is basically instantaneous, even for a huge file. Also, Linux writes to memory first (not the disk), so the writing is very fast too. My understanding is that the data gets written from memory to the disk a little later, the user hardly notices the delay, and everything is very fast. I do not know the inner techical details, but the effect is easy to demonstrate by using "cat" on a large file, and then the second time the result is instantaneous.

Some may question that I messed up, and it's not believable results are exactly the same. I understand that, because I have read so many glowing recommendations for SSD storage. Well, it is possible I messed up, and I would be open to any suggestions. But I have used Unix for decades, am very familiar and adept. Here are more details how I did comparison: The HDD test was run with the SSD not mounted. So there is no question about that result. For the SSD test, I renamed /home directory to /home.old (to get the HDD files out of the way). Next, I created /home directory with same permissions, and did "mount /home", verified lost+found present there. Next, I used rsync to make exact duplicate of files in /home as /home.old directory. I used Unix time command and read the "real" time as the result. All the temporary files, .o files, source files, output files are under /home directory, /tmp directory not used. I set TMPDIR to be under the /home directory, to make sure things were not being written to /tmp directory. I verified that everything was taking place in the /home directory (not in /home.old directory).

To test the idea that the file caching is behind the same performance in these repetitive tasks, I rebooted the computer, and from a fresh start (no source files cached) just did one compile. With the SSD, the single compile took 3.77 seconds, the HDD single compile took 5.62 seconds. That's a big percent difference, the HDD takes 50% longer. But the absolute difference is about two seconds, not a big deal. It is consistent with the idea that the SSD does much better on the FIRST read, but no difference once the file is cached.

I did another "time cat file > /dev/null" test with a 4 GB file after a fresh boot. The HDD took 3.83 seconds on the first time, 0.057 seconds the second time (file is cached). The SSD took 0.76 seconds on the first time, 0.059 seconds the second time (file is cached). So with reading a really big file the first time, the SSD is MUCH faster, only takes 1.5% of the time as the HDD. But again, the absolute difference is just a few seconds, and the second time the giant file is read, the time is identical.

Possibility 1) With a more powerful cpu (I have i3-4130), it's possible the disk would become the bottleneck, and the SSD would be useful on the repetitive tasks. But based on my understanding and observations of the Linux caching behavior, I doubt that.

Possibility 2) SSD is minimally helpful at best on a Linux system with real-world repetitive tasks, at least those in this particular development environment. This is a disappointment, I shelled out money, did not get desired result. It would speed up reading really big files the first time, but that seems about it.

Possibility 3) I'm missing something, not taking something into account, would like to hear how I can take advantage of the SSD.

When I look back at some of those glowing SSD reviews, I have to wonder if their benchmarks are realistic. Also, a review that only promises faster boot time is not much of an advantage in my opinion. I did not try comparing boot time on the Linux computer between SSD and HDD, because the boot time is normally of small importance to me, and it would be a bother to install Linux to the SSD for the comparison. How often do I boot a computer, and is it such a big deal if it boots in 10 vs 20 seconds? I do see an advantage with booting a laptop faster, where I usually want quick access.

Anyway, I am planning to probably move the SSD off the linux, because it speeds up little or none, at least for the real-world programming / data tasks I do. I have not tried the ssd on the windows 7 computer (under construction) yet, where I will mostly do word processing, email, etc. Maybe it will help there.

The other thing I should mention is that the 250 GB SSD has about 50 GB of files on it. So there is not a performance problem from the SSD approaching being full.

I look forward to any responses, anyone else who has done other real-world tests, anyone who might point out something I'm missing.

Daniel

 

[getochkn]

The compiling and html and probably even help files, are all very small files. There isn't a lot of reading or writing going on, it's all CPU usage.

The other thing you are probably not considering is that the flavor of linux you are using isn't optimized for your motherboard SATA controller, is TRIM enabled, is the system running in ACHPI mode. I know there was a huge difference in the performance on my SSD after installing the AMD chipset drivers. Not sure how linux handles this.

I think the smaller files are the issue though and the fact that the tasks you aren't really using the HD. Loading up some HTML or .C files isn't a big impact on any drive.

In Windows at least, I just did a real world test. I took a 6GB movie file, copied it the root of my 3 drives and then made a copy of each of file on that drive, to just measure the performance on copying the file only on that drive.

Green WD - avg 60mb/s
Seagate 7200 - avg 90mb/s
SSD - avf 210mb/s


Clear difference there in copying big files with a sustained read/write rate.

 

[dagoldman]

Thanks for the response.

The HTML files are each around 30 KB size. There are about 300 of them. Each one is converted through a series of about 8 steps. At each step, the script saves an intermediate file. So there a lot of file reading and writing. You're right the files are not huge. You could consider these files "very small" compared with 6 GB, but they are typical for what goes on in the life of a programmer, seem a reasonable real-world situation.

The help files are smaller, about 5 KB each. There are about 75 of them, and about 50 are actually used by a particular version of the software, so about 20 * 75 files are converted. Again, they are converted to the final form through a series of about 10 steps, with intermediate files created, so there is a lot of IO. In this case, I would agree the files are small.

BTW, I use the intermediate files so I can see what is going on at each step, in case some kind of glitch.

The source code has about 3 MB of .c code and about 10 MB of .h header files. It's a fair amount of source code, and I think a realistic test. The .h files get repeatedly included. In other words, each of the 20 or so .c files includes most of the header files. Plus, of course there are system header files and library files that get read. Again, the compilation happens repeatedly, for each software version. It is compiled in a very standard way, no kind of customized intermediate files.

Trim is not enabled. I think trim would slow things down. I was planning to add later as a cron job.

I did not try to optimize for the SATA controller (do not know how or if possible), and have not tried installing any special drivers, do not know if there are special drivers available for the ubuntu, am also not sure how linux / ubuntu handles this.

I don't know about ACHPI, will need to do some research on that. If this is the same as ACPI I don't have anything special turned on, use the default BIOS settings.

Your results (on windows) with the 6 GB file are consistent with the test I did on the really big file, reading it once after a fresh boot. I appreciate your doing the test and thanks again for all the suggestions.

Daniel

 

[ex_bubblehead]

Many things wrong with your little test.

1. Did you secure-erase the SSD before partitioning?
2. Did you align the partition/s on 1MB boundries?
3. What file system are you using?
4. Where is /tmp located?
5. AHCI is required for trim support.
6. Kernel options must be set correctly in order to support trim. (Ubuntu may already do this by default)
7. You should be using MUCH larger files, on the order of 32-64MB at a minimum. Your HTML files alone will all fit in the spinning drive's cache, thus masking the inherent latencies.

A properly configured SSD will beat a spinning drive in most tests.

 

[powerhouse32]

I did some checking on my PC:

All drives are LVM formatted! I used a 1GB test file created with
fallocate -l 1G test.img

Then I copied using the bash time utility, copying the file onto the same drive:
time cp test.img testcopy.img

SSD: 691MB/s (1.48s)
WD Green 2TB HDD: 67MB/s (15.3s)

2xWD Green 2TB in stripe mode (like RAID0): 272MB/s (3.76s)

When running backup from internal HDD to external HDD connected to USB3 port I get ~90MB/s.

So much for the tests, which are a little unscientific as caching will likely have influenced the results using such a "small" file.

Now to tuning the system. Trim is enabled in the /etc/fstab file. You need to add the "discard" option to your drive/partition entry for the SSD:
/dev/mapper/vg-root / ext4 noatime,nodiratime,discard,errors=remount-ro 0 1

Note the above entry is for a LVM drive, yours will probably be like /dev/sda2 or similar. Add discard to all SSD partition entries.

Another IMPORTANT step is to move your tmp folders into memory. Add the following lines to your /etc/fstab file:
#force temporary files to be stored in memory instead of on disk
none /tmp tmpfs nodev,nosuid,mode=1777 0 0
none /var/tmp tmpfs nodev,nosuid,mode=1777 0 0

That last step can really speed up your performance, unless your CPU is the bottleneck.

Another SSD related tweak is changing the scheduler, though this should have little effect (if at all). Edit your /etc/default/grub (Ubuntu or Debian) file and add "profile elevator=deadline" as follows:
GRUB_CMDLINE_LINUX_DEFAULT="profile elevator=deadline"

Then run sudo update-grub and reboot. See if it makes a difference.

4GB RAM is a bit on the low side. You might want to increase it, particularly if you run the /tmp and /var/tmp in RAM.


EDIT: Just saw the above post - I second the advice. The 1MB boundaries can be critical, but as far as I know partitioning tools nowadays take that into account. Still might be worth checking. I just assumed you use ext4, but who knows - some people use ntfs for compatibility with Windows and that is usually much slower.
Last not least, make sure there is always at least 20% empty space left on your SSD (it doesn't matter which partition, can be multiple partitions adding up to that amount).

EDIT 2: Just tried with a 4GB file:
SSD: 528MB/s (7.75s)
WD HDD: 33MB/s (123s) :-(
2xWD in stripe: 74MB/s (55s) :-(

 

[dagoldman]

I greatly appreciate your comments and suggestions, even though I don't think they hold water. This is very helpful getting feedback on this forum.

1. Did you secure-erase the SSD before partitioning?

No, I did not secure-erase the SSD before partitioning. I marked the entire SSD as one partition. I boot from the HDD, the SSD is not bootable as I have it set up. I had never heard about secure erase before. Do I really need to secure erase a brand new SSD? The articles I read, such as:

https://wiki.archlinux.org/index.php/Solid_State_Drives#SSD_Memory_Cell_Clearing

suggest that secure erase "resets an SSD's cells to the same virgin state they were at the time the device was installed". But the SSD is already in a virgin state (unless they cheated me and sold me a used one!). And my tests indicate the SSD is much faster the first time reading a large file, so SSD seems to be working fine. The difference seems to be the linux caching.

http://www.unixmen.com/secure-erase-your-ssd/ suggests there is a lot of skepticism about secure erase. Do you have any references (I could not find any) to suggest that secure erase is really needed with a brand new SSD? I don't want to go on a wild goose chase.

2. Did you align the partition/s on 1MB boundries?

Yes, as best I could tell. I followed the directions to make sure the SSD was aligned properly, according to:

https://wiki.archlinux.org/index.php/Solid_State_Drives#Partition_Alignment
# blockdev --getalignoff /dev/sdb

It returned zero. Is there some other test you would suggest to verify SSD is aligned properly?

3. What file system are you using?

ext4

4. Where is /tmp located?

/tmp is on the bootable HDD (not SSD). But my post clearly explains I set TMPDIR to be on the SSD and otherwise made sure all the files in the scenarios are being read from / written to SSD. I verified all the compiler temporary files were NOT appearing in /tmp directory.

5. AHCI is required for trim support.

The brand 250 GB Samsung 840 EVO SSD only has 50 GB of data copied to it. I could try running trim, that would be easy enough. But my tests indicate the SSD is much faster the first time reading a large file, so the SSD seems to be working well. But from then on, it does not seem to matter, because the file is cached by linux.

6. Kernel options must be set correctly in order to support trim. (Ubuntu may already do this by default)

Same answer as 5) - I don't see how trim could have anything to do with this testing on a brand new, 20% filled SSD. And it seems to me the results can be explained by linux caching files.

7. You should be using MUCH larger files, on the order of 32-64MB at a minimum. Your HTML files alone will all fit in the spinning drive's cache, thus masking the inherent latencies.

What do you mean "I should"? That's silly. Why would I want to use larger files if smaller ones work fine? I use computers to carry out a job. And these files are not small. There is 3 MB of C source and 10 MB of C headers being compiled, I think that is a pretty sizable amount. And even if the files were larger, they would still be cached. If the SSD does not improve performance in real-world tasks, then some theoretical advantage is of no benefit.

If you are suggesting that HDD performs as SSD reading files less than 32 MB, do you have any data to support that? If that's really the case, I would like to know. I thought the SSD was faster at reading and writing files, regardless of the file size, because the SSD has much better seek time and data transfer rate.

A properly configured SSD will beat a spinning drive in most tests.

I would like to be proven wrong. Do you have any real-world data to present, and an outline of the task being timed? I have no ax to grind. I am not "for" or "against" SSD. I bought an SSD, so obviously I want to use it!!! But I put more faith in real world tests than claims or artificial benchmarks. I hope I'm proved wrong and the SSD can really make the linux run a lot faster. BTW, I forgot to mention the ubuntu is 64 bit version installed.

Daniel

 

[ex_bubblehead]

It's obvious you just want to argue with anyone that tries to help.... I'm done here.

 

[dagoldman]

Thanks much for doing the tests.

Then I copied using the bash time utility, copying the file onto the same drive:
time cp test.img testcopy.img

SSD: 691MB/s (1.48s)
WD Green 2TB HDD: 67MB/s (15.3s)
2xWD Green 2TB in stripe mode (like RAID0): 272MB/s (3.76s)

That agrees with my "time cat bigfile > /dev/null" test with a 4 GB file (BTW, I may have misread, I think it was 0.4 GB but the principle is the same) after a fresh boot, where SSD is 0.76 and HDD is 3.83 seconds. But the second time (file is cached), the times are 0.059 seconds and 0.057 seconds (identical). The difference is that your copy command tests both reading and writing. What happens when you run it a second time? Here is a test on my HDD with the 400 MB file, after a fresh boot.

-rw-r--r-- 1 dgoldman ehdp 405880272 Nov 20  2002 RES42502.01
$ time cp RES42501.01 temp.x
real    0m3.798s
user    0m0.004s
sys     0m0.244s
$ time cp RES42501.01 temp.x
real    0m0.003s
user    0m0.000s
sys     0m0.000s

This seems to come to 106 MB /s with the WD10EZEX 1 TB hard drive. The part about my tests that makes best sense is that files gets cached, so subsequent reads are super-fast from the cache. The part harder to understand is what happens when files are written. There I would think the SSD would always be faster, but you can see the second copy command is basically instant. My suggestion is that linux writes the output file to RAM first, or the output file is buffered by the HDD cache, and somehow the file actually gets written to disk later. The time command finishes when the file has been written to cache, but the file is not on the disk yet. But this is admittedly speculation on my part, I do not know the details of how linux caches input / output.

I cannot do the comparison between HDD and SSD on the copy test right now, because I took the SSD out of the linux case for the time being. Nobody responded when I posted to the storage forum, so I kind of gave up, decided to use the SSD for the new windows 7 system. But I have NOT installed the windows 7 yet, the SSD is still in same condition as when in linux box. So I could move the SSD back and do some more tests. I would like the linux to go faster. It's my main work environment. However my guess, based on all the previous single file tests, is the SSD will be much faster than HDD first time, but the same speed on second time (uses cache).

So much for the tests, which are a little unscientific as caching will likely have influenced the results using such a "small" file.

I might disagree. If caching is going on, and if that makes the SSD not of benefit, that's something I want to know. I am not "for" or "against" SSD. I'm just for better overall system performance with real-world tasks. I would say it is unscientific to ignore caching. You are right that there is a limit to how big a file can be cached, so that's a good point.

Now to tuning the system. Trim is enabled in the /etc/fstab file. You need to add the "discard" option to your drive/partition entry for the SSD:
/dev/mapper/vg-root / ext4 noatime,nodiratime,discard,errors=remount-ro 0 1

Note the above entry is for a LVM drive, yours will probably be like /dev/sda2 or similar. Add discard to all SSD partition entries.

I don't understand how adding trim to this brand new, state-of-the-art SSD only 20% filled would speed things up. It would be easy for me to run trim when I get the SSD back in the case, but I would bet anything it would not help. The single file test indicates the SSD is MUCH faster than the HDD on the first time, and the speed up is in line with what you observe. But my conclusion is that once the file is cached (by linux or the HDD) the SSD has no advantage.

Another IMPORTANT step is to move your tmp folders into memory. Add the following lines to your /etc/fstab file:
#force temporary files to be stored in memory instead of on disk
none /tmp tmpfs nodev,nosuid,mode=1777 0 0
none /var/tmp tmpfs nodev,nosuid,mode=1777 0 0

That last step can really speed up your performance, unless your CPU is the bottleneck.

I appreciate the suggestion. I read about tmpfs, and would like to try that. But it seems beyond the question about HDD vs SSD.

Another SSD related tweak is changing the scheduler, though this should have little effect (if at all). Edit your /etc/default/grub (Ubuntu or Debian) file and add "profile elevator=deadline" as follows:
GRUB_CMDLINE_LINUX_DEFAULT="profile elevator=deadline"

Then run sudo update-grub and reboot. See if it makes a difference.

If little effect expected, I probably won't try it.

4GB RAM is a bit on the low side. You might want to increase it, particularly if you run the /tmp and /var/tmp in RAM.

It actually has 8 GB, and it is 64 bit ubuntu. I wasn't super clear about that and I my post was super long, but it is listed in the specs. I appreciate your patience.

EDIT: Just saw the above post - I second the advice. The 1MB boundaries can be critical, but as far as I know partitioning tools nowadays take that into account. Still might be worth checking. I just assumed you use ext4, but who knows - some people use ntfs for compatibility with Windows and that is usually much slower.

Yes, ext4 and it seems no boundary problem. The SSD is much faster than the HDD the first time, SSD seems to be working fine. Any suggested way to verify about the boundaries, other than "blockdev --getalignoff" command?

Last not least, make sure there is always at least 20% empty space left on your SSD (it doesn't matter which partition, can be multiple partitions adding up to that amount).

Thanks. It's a Samsung 250 GB 840 EVO, installed within past few days, with 80% empty space, only filled once before doing tests. There is a single partition, it is not bootable.

EDIT 2: Just tried with a 4GB file:
SSD: 528MB/s (7.75s)
WD HDD: 33MB/s (123s) :-(
2xWD in stripe: 74MB/s (55s) :-(

I agree that SSD is MUCH faster when reading (and probably when writing) a 4 GB file for the first time. I pointed that out in the original post. But in a way that is just an artificial benchmark. It shows a potential for better performance, but that has to be verified where the rubber meets the road. I bought the SSD because of the potential. Even if the money was wasted, I needed to check it out.

I guess this post is from the point of view of a professional programmer writing software on a linux computer, who was hoping to see speed up with SSD in the tasks normally carried out on a software development project, and did not see any speed up. Obviously, if someone else has a situation where an SSD speeds things up for them, I'm all for that. But I think it needs to be tested with a real world scenario, not just accepted that an SSD is "zillions of times faster" as one article put it, without any supporting data.

You have been very helpful, because you have provided real data, and I appreciate it.

Daniel

 

[dagoldman]

It's obvious you just want to argue with anyone that tries to help.... I'm done here.

I don't just "want to argue with anyone that tries to help". I want to have a discussion, and figure out if I am doing something wrong in my tests or missed something. And if the tests are correct, it's something that might be helpful to others. Am I supposed to just accept everything you (or someone else) says? That would be silly on my part.

I appreciate you tried to help and I said so. I didn't say anything bad about you. Yes, I disagreed with some of your assertions. So what? Real-world tests with data are more credible than unreferenced assertions. I answered all your questions, responded to all your suggestions. Your little attack on me in return that I "just want to argue" is not helpful.

I would like to get back to the discussion, and do appreciate you tried to help.

 

[Ijack]

You are correct. Disk caching is very efficient in most modern OSs so repeated use of the same file does tend to be very quick if you have enough RAM.

The only question is why did you expect anything different?

 

[dagoldman]

You are correct. Disk caching is very efficient in most modern OSs so repeated use of the same file does tend to be very quick if you have enough RAM.

The only question is why did you expect anything different?

That's a great question. Assuming the test results I presented are correct and the SSD is wasted expense, I guess the answer is:

1) I let my false hopes get the better of me, based on the many glowing SSD reviews I saw that said adding an SSD would be the best way to improve performance, and made no mention of caching.

2) I chose to ignore (did not even think about) my previous knowledge, based on experiments, that linux disk caching leads to almost instantaneous operations once a file has been read.

In retrospect, I would have been better off looking for more performance by spending the extra money on more cores / threads, getting an 8 thread xeon cpu vs the 4 thread i3-4130 that I got. I previously did not think the extra cores were utilized that much, again based on some articles I read.

But I was missing some obvious facts I should have seen. At the same time I have been building this computer, I have learned all about "make -j" and xjobs and really learned to take advantage of all the cores under linux, leading to dramatic performance gains. It did take some reprogramming shell scripts to make sure that none of the parallel processes "stepped on someone else's feet" by possibly overwriting a file involved with a different parallel process.

But the reprogramming is over. Now that I see the potential, I may perhaps use pthreads to refactor the data analysis software itself so it runs on all available cores. Each core would be assigned to analyze one year of data, and then the results would be put together at the end. I just never thought of how to take advantage of the cores before, had never thought about it.

Another obvious better alternative might have been more RAM. Well, nothing is perfect, I'm quite satisfied with the new ECC PC, but it seems a mistake to get the SSD. You wanna buy a brand new SSD, only driven once on a Sunday?

It sounds like you are suggesting that the SSD (Luckily, only got one!!!) will also not have much beneficial effect if I install windows 7 to the SSD, for the second ECC PC I am building. Any suggestions about that?

Thanks,
Daniel

 

[skittle]

For gods sake man if you are so worried about performance just load everything into RAM and work from there.

RAM is cheap, buy 16GB of RAM, make a RAM disk, load your work files into that and quit bitching about your 'slow' performance or 'wasted' purchase.

SSD are much faster than HDD at EVERYTHING. Period.
Sorry if your particular application does not fully take advantage of SSD's performance advantages.

Seriously you are border line trolling now. Stop.

 

[Ijack]

SSDs have many advantages over mechanical disks, particularly for those manipulating several large files (not the same few small files time after time), or random access files (compiling tends to use files in a linear fashion, which an OS can easily optimize). They improve boot times appreciably and are quieter and more power efficient than mechanical disks. They tend to be faster at reading than writing and, depending upon the particular disk, the difference can be very signigicant.

You have tested your SSDs in the very poorest circumstance - multiple use of the same input files and a large proportion of writes to the disk, all on very small files. The average user doesn't really perform 500 or 1000 successive compiles of the same file but will be accessing new files, mostly read access, so will see a much greater performance boost than in your artificial tests.

If your use is mainly compiles, particularly multiple compiles of the same file, then I would consider (in probable order of importance), RAM, CPU power, I/O performance. But, if you are really interested in performance improvements, the first thing that you need to do is to measure various aspects of your current system to discover where current bottlenecks are. If you have 1GB of RAM and a single-core CPU then I suspect that I/O performance is the least of your worries. On the other hand, if you have 16 GB of RAM and an 8-core CPU, and have measured that there is an I/O bottleneck, an SSD would probably provide a significant improvement.

 

[powerhouse32]

I would start with some "best practice" settings:

1. trim enabled
2. tmp file systems in RAM - definitely not on HDD !!!
3. The rest of the settings seem to be OK.

If that doesn't show any difference in performance between SSD and HDD, then - with all probability - the bottleneck is somewhere else. An i3 CPU isn't the fastest, so that could be a potential bottleneck. Even connecting the SSD to a SATA 6Gb/s port versus 3 Gb/s port could make a difference. I assume that AHCI is enabled, but if in doubt you could check in your BIOS settings to be sure.

The point is, at least 2 people have posted benchmarks that indicate that SSD is substantially faster (when using large files). Try to get an optimal setup as suggested, and if that doesn't help, it may be better to invest in a stronger CPU. I can guarantee you that my i7 3930K system will give you better results.

 

[dagoldman]

SSD are much faster than HDD at EVERYTHING. Period.

That's what I repeatedly read in those glowing reviews I mentioned. But it misses the point that caching overrides that performance difference much of the time.

You have tested your SSDs in the very poorest circumstance - multiple use of the same input files and a large proportion of writes to the disk, all on very small files.

I don't think this is "poorest circumstance" at all. These are not artificial tests that I devised. Yes, two of the tests repeatedly used the same input files, but the third did not. And there were many intermediate files, with reads and writes, so it's not just re-reading the same files. 3 MB of C source files and 10 MB of C header files don't sound like "very small files" to me.

But, if you are really interested in performance improvements, the first thing that you need to do is to measure various aspects of your current system to discover where current bottlenecks are.

I agree. As I said before, if I was going to spend the extra money I should have gotten a cpu with more cores, since I can take advantage of them. It is obvious that's the bottleneck because I can easily verify that if I double the number of cores, the time drops in half. I explained how I made the wrong decision. Maybe someone else can learn from my mistake. On the other hand, a user just running single thread programs may not benefit much at all from all the extra cores. That reinforces your point.

The average user doesn't really perform 500 or 1000 successive compiles of the same file but will be accessing new files, mostly read access, so will see a much greater performance boost than in your artificial tests.

These were not artificial tests. That's the whole point. And these are not 500 or 1000 successive compiles of the same file. Each time there are different intermediate files that get written and accessed. This is totally real-world.

I'm just reporting some facts I observed. I seem to have stirred up a lot of reaction, and I apologize to anyone who thinks I am "trolling", which is of course ridiculous. I'm not advocating for or against SSD devices. Obviously, if someone reads a 4 GB file the first time, the SSD will be MUCH faster. If that is what someone is doing on their computer a lot, then the SSD will speed things up a lot, and that's great.

I also transform (ETL) very large data files, and have not yet done any tests comparing SSD and HDD on those operations. Some group members seem to be a dislike for this kind of data-driven analysis, seem to already know the answers. Given some of the strong reactions, bordering on personal attacks, I will probably not post any ETL results. I apologize to those who seem to dislike this thread. Perhaps it's because this kind of analysis is so much longer and detailed than a simple question. I don't need any more input. Even my question about the windows 7 caching I can figure out myself with some testing. I appreciate the constructive suggestions I got.

I would start with some "best practice" settings:

Added: Thank you very much. Those are very reasonable suggestions. Yes, I kind of regret not getting the better cpu, but it's too late now, and not a big deal, I'm really pretty happy with the system.

 

[Ijack]

When I say "in the poorest circumstances" I do not mean it to be pejorative in any way. It is just a simple fact that, in the sort of tests that you did, SSDs are likely to show the smallest advantage over normal HDs (apart fro noise and power consumption, of course). I can assure you that with Gentoo Linux running on an i7 with 8 GB of RAM the increase in performance is very obvious in almost all tasks; particularly those such as compiling a kernel. And I haven't even optimized my setup for an SSD yet; this thread has given me some good tips, which I am now following up, to optimize performance een more.

 

[chamaecyparis]

Why someone would use such an SSD as the one in question or the 840 Pro for anything but a boot drive, I cannot fathom!

 

[Aristotelian]

I recently had my SSD go bad so I can tell you HDD is significantly slower. For one thing, SSD boot time for Linux Mint 16 Cinnamon was 7 seconds vs >20 seconds with HDD.