| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: Getting work |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 6
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I have one host, (8 cores) that only connects about once per day when I manually connect it. It is running BOINC 6.4.7.
Since I can only connect with it once per day, I like to grab a large number of WU's at a time. Currently I do not seem to be able to get more than about 50 WU's (+/- 10) which it finishes in about 24 - 30 hours. When the queue reaches this point, the first 8 jump to high priority, which prevents the client from fetching any additional work. So far this has been ok, since I can connect it every 24 hours or so, and it doesn't usually sit completely idle. However, over the weekend, I will not have this option, and I would like to be able to queue more work for it to crunch. I have tried: Running WCG exclusively editing client_state.xml to reflect the following: <on_frac>1.000000</on_frac> <active_frac>1.000000</active_frac> Trying different time frames in the additional work buffer settings. Any suggestions on how to acheive a larger queue? Preferably about 3 times what it is receiving now. I would like to cache 3 days work, or approximately 150 WU's. Thanks for consideration. |
|||
|
||||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Try waiting. There is a limit to the amount of work that will be sent in a single request. Stay connected long enough to get all the work you need.
Note: our recommended BOINC version is 6.2.28. If you want further diagnostics, please supply your complete message log. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I don't have access to the machine again until tomorrow, but can copy/paste the log then.
----------------------------------------The problem is not with WCG sending work, but that when the tasks jump to high priority, the client stops requesting work. deviceId=895828 Edit: Also, the estimated time to completion for the tasks, is pretty accurate, so it's not an issue of duration correction factor as far as I can tell. [Edit 2 times, last edit by Former Member at Apr 23, 2009 2:45:04 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Well, I did figure out how to "trick" it into getting much more work.
I put in an artifically low value for the duration correction factor in the client_state.xml still doesn't answer the question of why it jumps into panic mode with 1 day cache and a 10 day deadline. I've gone through the logs, and it's really nothing more than transfers, and requesting and getting work, there are no other messages. It simply stops requesting new owrk once there are tasks running in high priority. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
High Priority processing stops work requesting, nothing new there. So what was the rDCF for WCG and what are the new net connection fractions saying? Work limits? Not heard anyone complain with 16 and higher core devices, dual nehalem's on full hyperthreading and all about not getting their quota filled on 24/7 machines. Not knowing the current limit but at least 128 I think is the number... you'd see a quota statement anyhow in the message log.
----------------------------------------Anyway, seeing all the hacking notes and still no message log to gloss over, I quickly loose interest to pain the brain over why that is happening, , others did already it seems. Clean out all work, exit BOINC, delete all client_state.xml files and restart BOINC allows for clean slate start is the base solution to most "don't understand" issues on a recalcitrant client. Staying connected for longer so BOINC can find it's balance rather than having to cram everything into a brief moment of contact may be part of the solution. And we still recommend 6.2.28 for windows based clients. 6.4.7 is serious hmmm and long outlived it's useful live to just get GPU computing off the ground. Honestly, there is no keeping up with what Berkeley keeps changing to the client and the scheduler, so take a confirmed, known version and wait till WCG endorses some 6.6 client, X weeks/months in the future.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
And we still recommend 6.2.28 for windows based clients. 6.4.7 is serious hmmm and long outlived it's useful live to just get GPU computing off the ground. Honestly, there is no keeping up with what Berkeley keeps changing to the client and the scheduler, so take a confirmed, known version and wait till WCG endorses some 6.6 client, X weeks/months in the future. v6.2.28 isn't an option for anyone using GPU, and anyone also participating in one or more BOINC-projects with 64-bit applications. Now, it seems Steven Pletsch also runs gpugrid, but possibly not on this particular computer, but still a fair guess is that v6.2.28 isn't an option for him. So, a more likely suggestion is to upgrade to v6.6.20, since v6.4.7 has significantly more problems than v6.6.20. Or possibly try one of the later v6.6.2x alpha-builds... Anyway, as for "high priority", possible other BOINC-projects, and the cache-settings, both "connect about every X days" and "cache additionally Y days" is a good starting-point...  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
|