Thread 'Problem with CPU work request, BOINC 7.0.28'
Message boards : BOINC client : Problem with CPU work request, BOINC 7.0.28
Message board moderation
| Author | Message |
|---|---|
|
Send message Joined: 9 Apr 06 Posts: 302 |
09/09/2012 00:58:30 | SETI@home | [sched_op] Starting scheduler request CPU was idle, no work was downloaded for CPU... but on the next work request BOINC doesn't request work for CPU also, it shows no idle CPU devices in request though no CPU tasks were downloaded and CPU completelly idle still. New bug or known one ? ID: 45595 ·  |
 Send message Joined: 21 Mar 09 Posts: 33 
|
It is known, mainly BOINC is trying to fill up the most efficient device first. There are a lot of posts on the main SETI boards about this problem. ID: 45596 · |
|
Send message Joined: 5 Oct 06 Posts: 5139 
|
What were the values of dt and inc shown in [WFD]? 08/09/2012 22:36:41 | Milkyway@Home | [work_fetch] CPU: fetch share 0.000 rsc backoff (dt 2289.16, inc 4800.00) If dt > 0.00, fetch is inhibited for that resource - no point in hammering a server with requests for work when they haven't finished writing the app yet... ID: 45597 · |
|
Send message Joined: 9 Apr 06 Posts: 302 |
It is known, mainly BOINC is trying to fill up the most efficient device first. In my case it did just reverse - it fills up not idle device leaving idle one empty. ID: 45598 · |
|
Send message Joined: 9 Apr 06 Posts: 302 |
What were the values of dt and inc shown in [WFD]? Sorry, I don't quite understand this. 1. It's CPU device and app for CPU presents in app_info. 2. On next request (after another 5 min of idle CPU) BOINC started to make CPU work requests too (and finally got it). So I don't understand how "no app" example is relevant here. More verbose log citation: 09/09/2012 00:53:15 | SETI@home | Requesting new tasks for CPU and ATI As one can see, BOINC stopped to ask for CPU work when GPU tasks finished. Why finish of GPU task connected with CPU work request inhibition ??? ID: 45599 · |
|
Send message Joined: 5 Oct 06 Posts: 5139
|
What were the values of dt and inc shown in [WFD]? It isn't. CPU work request inhibition is caused by Scheduler request completed: got 0 new [CPU] tasks With [Work_Fetch_Debug] you would have seen that GPU fetch was also disabled at that point, for the same reason. 'Computation for task 27mr10ac.13328.12751.12.10.242_0 finished' cleared the request backoff for that resource type (only) - it must have been a GPU task, because the replacement task has version 610 and plan_class ati13ati. So, the next work request is for the not-backed-off resource only. That's all according to design specification. Work fetch backs off when no work is received in response to a request. Where I agree with you is that the duration of the backoff should be related to the reason for the lack of work. My backoff was because MilkyWay haven't finished re-writing the N-Body Simulation application for Windows yet. Another week or two in backoff would have been acceptable. Your backoff was because the BOINC server design can't hold sufficient tasks to fulfill a work request for 2 days GPU crunching in one go, chooses (preferentially) to supply work for the faster resource, and, I suppose, gives no extra weight to the idle resource when choosing which part of a mixed request to give priority to. ID: 45600 · |
Copyright © 2025 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.