Not to worry I moved them over to other projects for now.

There's a button for that problem... BOINC spending more time on managing the task queue and refreshing the screen than the tasks... Hit the "Show active tasks" button in left margin. It is not supposed to be a problem long as the BM is minimizes to system tray [not minimized to start bar], as then there is no screen refresh needed.

BOINCTasks alternate multi-client manager is superior [runs on all 3 main supported WCG platforms], as you can contract tasks by their class in the view. I've got it set to filter the Ready to Start tasks, so the view only shows the total tasks *per science app* and their estimated run time total, whilst showing the detail for the running jobs. Also BOINCTasks shows in the project view the total estimated run time per core... so you always know how much work there is until the client goes idle. Refresh times can be set. I've got it on low, for reduced use of CPU cycles. Mine has used 9:34 minutes per Task Manager and has been up for 3 days since last boot and monitors remote clients at that too.

--//--

It's known... the core client not able to handle queues of several thousands, and the button added to reduce the additional load set by the BM. That said, some asynchronous file handling elements are being introduced in version 7, so this may be a good chance to test on alpha 7.0.24. Think it's a candidate to get pegged for Beta. Been running it since 2 days, but not HCMD2. Get it here: http://boinc.berkeley.edu/dev/forum_thread.php?id=6698&nowrap=true#43219

--//--

edit: added link to official announcement post. Linux build of either 7.0.24 or 7.0.25 coming soon.

HI Yves!
I have no answer to this real problem but I can confirm it does exist, even when running with BOINC Manager only showing active tasks (this is for Rob ), but anyway you also said that it happened to you with machines not running BOINC Manager at all.

Since a few days I had it once a day, at various times, and already twice today.
Every time the BOINC client failed I rebooted this quad machine (Ubuntu 64-bit 11.10 + BOINC v6.12.33) and after the restart I also had one or two tasks running beyond 100 % that I had to kill, but I think this is another problem which only shows more easily these days with so short HCMD2 WUs that there is always one which completes during the shutdown.

After each restart I had a look at the message log files for messages happening just before BOINC fails. Unfortunately, before today I think I had not twice the same message and this is why I have not reported it yet: no consistent clues to offer to the techs.
However, every time the messages were related to something going wrong between the server and the client. For example, last times today (0:34:35 UTC and 15:37:43 UTC),
Requesting new tasks for CPU
Can't open client_state_next.xml: fopen() failed
Couldn't write state file: fopen() failed; giving up

I am also running HCMD2 with a 1 day cache (because of announced maintenance interrupts and also because feeding HCMD2 tasks is not always available over a day) but since this a quad the number of queued WUs varies only between 700 and 1,200, and this machine has no main or disk storage contention problems.

PS: I am sorry I cannot offer more error messages for earlier failures, but with so many tasks a day the stdoutdae files can hardly contain more than one day of messages. Messages for this morning's failure are already in the stdoutdae.old file.

Hi Jean,
it is nice to read you since so a long time.
Your observations fit perfectly with mine. I think, we have to deal with the same issue.
By reading your post, I came on the idea that the log file could maybe represent the cause of the problem. Could a very big log file cause that boinc does not succeed to manage it correctly?
At this time, I experience the problem mostly on two machines: Athlon II x2 (3.1 Ghz), Phenom II x6 (3.2 GHz).
One the Phenom II x2, the average running time for a WU is 3.5 minutes; i.e. over 2'400 WU /day (without crash), around 1.7 WU/min to manage (download, compute, upload, report).
Is this (reporting) workload the reason for the problem? ...
Yves