I'll admit to skimming the whole discussion, I just can't keep up. But wanted to point out two observations I've not seen posted.
I run with limited memory available to BOINC when "in use". And so whenever a task is suspended to "wait for memory", you DO need to consider rescheduling tasks. Currently, it seems to take the 60 seconds to kick in and look for another task to work on. It also seems to never willingly suspend the "first" task it is working on. I have many cases where one of the two CPUs goes idle because BOINC will not suspend that first task that has grown to consume more then half of BOINC's allowed memory. When I suspend it manually, there are often two other tasks that can run in the same memory footprint and keep both cores busy. i.e. I'm having to micromanage the machine. I think it should even consider getting new work from a project with low memory requirements to keep busy. I should be able to make up the debt over night when not in use. But it doesn't seem the client has any great way to know one project will tend to bring down tasks that could fit in the memory currently available. What it presently does it run through each Rosetta task in the queue, getting started on it, generally for 60-90 seconds and then finding it must wait for memory. And so BOINC has worsened my memory constraint and increased the page file size significantly by doing he same on 5 or 6 tasks for Rosetta, rather then seeking work from a low memory project. Aren't those the things I was hoping to minimize by restraining BOINC's allowed memory in the first place? My other observation on 6.6.20 is that the CPU time measurements seem to be having trouble. I run primarily Rosetta work (and should note that I am not a part of that project team, just a big fan). Their graphic shows the CPU time on the task. So I compare the three places I see CPU time and the figure shown in BOINC Manager is incorrect. Windows task manager shows total CPU time for the thread, and since I've not rebooted the machine, and leave tasks in memory, this matches the value shown in the graphic, one observed value was 17hrs of runtime. BOINC Manager shows the CPU time in the task list in the advanced view. This shows what is often several hours more for the task. Over 23hrs when the other places indicate 17. This seems to be reflected in the estimated runtimes as well, which show over 30hrs, even though all tasks have completed in less then 25. The % complete matches within rounding differences between the graphic and BM. I am not certain if the 23hrs figure would be wall-clock time or not. It is difficult to tell when tasks reschedule due to the memory constraint. I don't generally keep the bleeding edge application installed, so I'm not positive when this behavior began. But at least between 6.2 and 6.6 it began this misrepresentation of time. Thanks to all that are working to harmoniously resolve the contradictions in how people use BOINC. Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running rose...@home just might! http://boinc.bakerlab.org/rosetta/ _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
