hi depriens,

You say boinc is constantly reporting "connecting to client". If the BM is loaded, unload it. A source of RPC consumption and a drag on many tasks. My Linux box e.g. has nearly 700 on them, just 4 cores for 3 days.

A coming client [my test client has it] is going to put a hard cap on the number of tasks a project can buffer [1000 IIRC]. A long standing issue, continually updating the list of tasks on board, not to speak of a memory leak source.

Whilst, see none of that. 8 cores on the 2670QM, and the BOINCStats history is reporting peak workset usages of 170MB...

... and then I looked again, strike the not seeing bit and take everything else as just FYI. All the A4OD/A4OE tasks list with about 500+MB memory use [some passed 523MB on Windows32+64 and 460MB on Linux64bit], but all the rest seems to be behaving. No drag here since having 8GB. Supposed it's just a big model/compound that's being tested.

What I did not say was, only inferred, that whilst these SN2S run 30-35 minutes, they do on Linux, you quickly end up with caching a whole pile of tasks, which is a pull down on the BM and core client performance.

(WCG tallied 2.5 million results yesterday, an all time record, due lack of AutoDock tasks in part I suppose, and SN2S being ramped up too. Someone mentioned seeing experiment 72 for FA@H, not specifying if new AutoDock or still AD VINA, in case you wish to escape to longer running tasks with a very low, per crunch hour BW consumption... 100KB for 7-10 hours as a result is excellent)

Hi,
with the new SN2S, I experienced several times a recurrent problem on my both AMD Phenom IIx6 - Ubuntu systems.
For unknown reasons, boinc stops working: no boincmanager, no task.
The only help is to reboot the system and it works fine again (until the next stop).
These both systems compute SN2S and CEP2 (max 2 WUs) and they are devoted only to WCG.
Within the last 3 weeks, it happened around 7 times.
There is no further indications for understanding what the reason could be.
Cheers,
Yves
---
There is sufficient available RAM (8GB and 16 GB) and disk space.
---

Had same problem on 5 of 6 machines. Finally got one working enough to look at memory and processes: Found that some WUs in the 4A0D and some in the 4A0E groups are using over 400,000 kb of memory for each WU! Those machines have "only" 2gb installed, so with 4 of these running everything was going to virtual memory. This locked up the machines trying to get to the hardisk so solidly that nothing else could get through and the machines were effectively locked up tighter than a bulls bum during fly season.

The one machine that was still working (my daily driver) has 3gb memory available so was able to handle the extra memory drain.

EDIT: forgot to mention, simply changing to 3 cores instead of 4 got through these WUs without further problems.

My prefs were set to use no more than 99.0% of memory, so this appears to have bypassed that feature. (It may be that the percentage chosed is total memory and not available memory.)