I know that memory is a limitation on my machine and without enough memory, some of the WU will have problems, but I normally use the machine for CPU intensive stuff not memory intensive. I wasn't really complaining about how WU, well maybe venting. Just wish boinc had some sort of priority control(or something so I can force work to be done in a certain order), so I don't have to monitor my systems too much.

Beware: If you have devices which should not reasonably process type A or B DDDT2 WUs you should not allow them to receive DDDT2 WUs at all.
Even if it may seem manageable nowadays to let them receive type C, you can never be certain that they will not receive one type A or B among the Cs, and when DDDT2 work flows more regularly (hopefully soon) all types will be distributed simultaneously.

anyone else noticing longer processing times for B.pe compared to A.ps?

While most Boinc Projects use between 20 and 50MB RAM there are some that only use about 10MB (Spinhenge) and there are other non-WCG projects that use lots of memory; The Lattice Project uses over 1GB RAM per task. Although these can be calculated there are also non-WCG projects that run different projects/task types (ClimatePrediction, Ibercivis, yoyo) that require different amounts of memory. Run two or three of these alongside WCG and you would be guessing how much RAM would be used by Boinc tasks.

Boinc needs to be more idiot proofed, to be able to better control which tasks run at the same, so as not to use up too much RAM. I know you can configure many settings to do with this; Disk and Memory Swap Usage, Page File, Memory Usage, Leave applications in Memory While Suspended, Task Checkpoint time and Switch Between Application Time. However it gets very complicated when different projects behave in different ways. Tasks from the WCG usually checkpoint well and keep reasonably accurate completion times, but other don't. So should you uncheck to keep projects in memory while suspended or not? For projects such as Lattice, Aqua and Yoyo you can easily lose all your work by messing with the settings, or just closing and opening Boinc.

Such memory problems are probably becoming more apparent because people are using systems with more threads and the number of Boinc Projects is large. I think CPU thread count is increasing faster than the relative amount of RAM in systems. There have always been unbalanced systems but now there are 8threaded 3GB systems. RAM is still expensive, and for crunching systems it'€™s a bit much to expect people to spend hundreds of pounds/dollars/Euros... just for additional memory.

One problem that became apparent to me was not having a small cache. When running longer tasks Boinc continuously switches from one task to another, so at times I could have 20+ tasks partially complete on the same system. Most annoying was seeing tasks at 99 or 100% that just needed another few seconds to complete, but Boinc calculated that it should be running other tasks (this really needs to change; at 99% run to completion). So the memory was quickly used up. As I was running tasks that would reset when Boinc is closed I had to sit over the system and suspend tasks to force others to run to completion and give up memory.

On the systems I don'€™t have much RAM in I now try to not run tasks that Fail or Reset when I close Boinc, because closing and opening Boinc forces tasks to be saved to disk and is an easy way to get more RAM back. Always saving to disk is slower. I also keep a very low cache and don't run tasks that use up lots of RAM, but this is hard work when you have several such systems, with different specs.

You can see how much Memory is being used by a task from within Boinc; just click on the task and then Properties (it shows the actual amount of RAM being used, so it won'€™t show anything for tasks that have not started or have finished).

Working on downloading a bunch of new work for this project. Look for rain tomorrow. Multiple inches of rain at that :)

-Uplinger