For BOINC purposes I have a Win7 (x64), 2 x SSD system, with one for the OS which also contains the BOINC system directory/files and the other contains the data directory/files.

Since day one BOINC has been running on HDDs and I am presuming that it has been optimized for that medium. With the prevalence of SSDs on the market has any thought been given to the optimization of the manager/client for this medium or does it not make a difference?

---

What kind of optimization are you thinking of?

---

I'm not sure what I'm looking for. As the speed of a CPU & GPU increases WUs take less processing time in their upgraded un-optimized (native code) and their optimized (i.e. Lunatics) states, it would therefore come to the question of how, if possible, to do something about how to use the speed of the SSD in I/O operations. Is it even warranted to even look at the possibility of increasing the speed of I/O operations on SSDs?

As an example on my old machine (i7/950, DX58SO, GTX660SC, 6GB, BOINC 7.3.19) AP CPU WUs took approx. 11~13 hrs. to complete and GPU WUs took around 3~5 hrs. using Lunatics 0.41. On my new machine (i7/4770K, ASRock Extreme4, GTX750Ti FTW 8GB, BOINC 7.3.19 -> 7.4.8) these WUs were cut almost in half with the CPU WUs averaging 4~5 hrs. and the GPU around 1~3 hrs. The GTX660SC gave the same results on the new machine. Please note that both machines had/have the same SSD configuration.

With my current processing times decreased, imagine what can be accomplished if this thought was possible.

---

The usage of HDD or SSD is "transparent" for BOINC. For every programm on the computer an SSD is just a faster version of an HDD (the program doesn't care). There is no optimisation by the program needed (and possible). The real optimisiations happen in the fast memory on a computer (RAM, L2-Cache) that's where optimised apps come into play.

Sure an SSD can speed up computation because the data is retrieved and stored faster but this is still less in what is possible with RAM and L2-Cache optimisations.

Regards
Christian

The usage of HDD or SSD is "transparent" for BOINC. For every programm on the computer an SSD is just a faster version of an HDD (the program doesn't care). There is no optimisation by the program needed (and possible). The real optimisiations happen in the fast memory on a computer (RAM, L2-Cache) that's where optimised apps come into play.

Sure an SSD can speed up computation because the data is retrieved and stored faster but this is still less in what is possible with RAM and L2-Cache optimisations.

Regards
Christian

Here's another question -- Which is the dominate factor L2-Cache or RAM and what is the determining factor in how much RAM is utilized? I have 8GB of RAM but, the most I've seen used in most SETI applications is 75MB. When an AVX app is running it can peak to approx. 151Mb. Total system usage of RAM is approx. 2.5GB peaking at 3, leaving at approx. 5GB free doing nothing. I have 5 WUs running at the moment using a total of approx. 219MB. BOINC Manager is using approx. 57.1. What is the possibility of increasing the limit of RAM being used? Even in the native code apps that will be an improvement.

I've noticed that on the 'Disk Usage and Memory' tab of the Computing Preferences' panel, I've indicated 95% usage of the page/swap file, but the file is seldom if ever used even though there's approx. 2GB currently allocated, and I can't tell if BOINC, SETI, or some other application is using it when it is being used.

I realize that most of my reasoning concerns SETI, which is my primary project, but I think that it can relate to the manager/client apps as well, based on the constraints/limits of the size of the free RAM. Right now I see approx. 7GB of space (free RAM + page space) not being utilized.. Or should maybe this type of question be addressed by the different projects developers?

---

Let's start with memory hierarchy: The fast the better! L2 is faster than RAM, RAM is faster than SSD/HDD! You as a user can not controll what is stored where. Only the application developer can do this.

Usually the fast L2-Cache is very limited (1 MB) and the developer has to make sure that internally used datasets are smaller than this. Everything else is stored in RAM (which is slower). How much RAM is used greatly depends on the application. Seti is designed to not use a lot of RAM (and wouldn't be faster if they used more), whereas factoring apps for example (sieve applications) tend to use more RAM because they have more data to process at the same time and need fast access to it. You as a User can't increase the RAM used by applications.

Using the Swapfile is very slow and should be avoided if enough RAM is available. I really don't know why this Option is there. But not needing the Swap file is a good thing actually.

The bottleneck in the general case is the speed of the CPU not RAM usage. There are edge cases like apps for factoring numbers that need a large dataset (several GB) available in RAM but they also utilize 100% of the CPU.

To sum it up: There is no problem if there is free RAM available. If you want to "optimize" your scientific throughput you have to buy a better CPU (or GPU).

Once the task is loaded into RAM, it doesn't access the hard drive. The only way an SSD would speed thing up is starting the task, and then resuming if it's not left in memory when suspended.

Upgrading your RAM might make a difference if you have older chips, but even with that, your processor is the main factor with something like BOINC.