| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: WCG sending too many work units |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 17
|
|
| Author |
|
|
Jim1348
Veteran Cruncher USA Joined: Jul 13, 2009 Post Count: 1066 Status: Offline Project Badges: 
|
OK, I would appreciate any input you might give. But the one machine that is working "correctly" now is my fastest, a Ryzen 3700x. So it has run through the most work units, and probably has had time to correct whatever estimates need to be corrected. I hope my other machines (Ryzen 2700 and Ryzen 1700) follow suit and correct themselves in due course.
----------------------------------------EDIT 1: It is probably just a case of the changes in the BOINC scheduler throwing all the estimates out of whack when you upgrade. If you start with a clean slate, you won't have that problem. EDIT 2: If anyone wants to speed up the convergence to the correct values, they can look at the link I posted, and I show a cc_config.xml file that will help. Thanks. [Edit 3 times, last edit by Jim1348 at Oct 8, 2019 10:59:44 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Don't know if this matches your case but I have run into problems in the past when contributing to multiple projects (other than WCG). EXAMPLE: I set my preferences for the WORK profile for WCG but then go to climateprediction.net and change my preferences for the WORK profile at climateprediction.net. It will override the preferences at WCG. It has caused me many hours of grief in the past to the point where I don't contribute to many projects outside WCG. When I do, I make sure the preferences are the same across all projects. You can set WCG at .10 days but then go to climateprediction and set that one to 3 days and over time WCG will have a 3 day queue. I don't particularly like that behavior but I haven't spent the time researching the preferences hierarchy and opening an incident. There has been several posts in these forums over the years where it has caught others as well. It may be worth looking at the global_prefs and global_prefs_override files and see if everything is as you expect it to be....
----------------------------------------Thinking about it a little more.. in the simplest case, there is only one client running on a machine (yes, I know with a little tweaking that isn't 100% true). The prefs and prefs_override files are in the <boinc_data> directory. If one has a WORK (or any ) profile at multiple projects and they aren't the same, how is the client supposed to know which one to use since there is only one prefs/prefs_override? What the boinc developers should do is move at least the prefs/prefs_override files to the projects directory. That way each project can have it's own set of preferences different from any other project. However, that would probably make the scheduling process and work fetch a ton more complicated. [Edit 2 times, last edit by Doneske at Oct 9, 2019 1:34:01 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
It's really simple, each connect to a project the client checks if the change date of a profile at that project is later than the one which is on the client. If it's newer, it gets imported by the client and an entry shows in the event log. If it's equal or older, no copy is taken.
----------------------------------------Don't know the mechanism of how the newer profile gets migrated from project A to project B. Think there isn't. Many profile prefs are 'global' i.e. if you set profile to 3 days, that copies to the client and that's it. The client asks for an X amount of work from anywhere until it got 3 days. It backfills and if it does not get enough from project A, it goes to project B and so on, if it is it's turn per the weighting and debt in the scheduler. Edit: Just wondering, anyone using "Cache n.n extra days of work". It adds to the minimum, 3 days in the example, but is capped at 10 days. Think that's hard coded in the client. What odds further is, there's an uptime/active equation. If that value is for instance 0.9, and cache goes over 9 days, you should get something like 'no work fetched, wont finish in time'. Values stored in client_state <on_frac>0.904405</on_frac> <connected_frac>0.907788</connected_frac> <cpu_and_network_available_frac>0.905388</cpu_and_network_available_frac> <active_frac>0.907596</active_frac> Whoever compiled the PPA version, think if it's a persistent error that can be reproduced across other installs, need to bring this to the developer mailing list and or the package maintainer for the particular distro. Looking over at official BOINC, there is no 'Official' Linux release since 7.4.22 [Edit 2 times, last edit by Former Member at Oct 9, 2019 8:56:41 AM] |
||
|
|
Jim1348
Veteran Cruncher USA Joined: Jul 13, 2009 Post Count: 1066 Status: Offline Project Badges:
|
Those are all good points. Those three machines are either all WCG, or else a mixture of WCG and Rosetta. But the settings on the Project Preferences pages of both are the default:
----------------------------------------Store at least 0.1 days of work Store up to an additional 0.5 days of work Also, I checked the BOINC log on each machine, and it shows General prefs: from World Community Grid (last modified 25-Sep-2019 16:44:01) General prefs: using your defaults So I am presumably just using the local default, as indicated above. I once lobbied on the BOINC forum to get rid of the miserable global preferences and just use your local ones to end the confusion. You can guess how far that got. [Edit 1 times, last edit by Jim1348 at Oct 9, 2019 1:56:27 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Not far, since when you're having 20 machines anywhere on the planet on 1 profile, a change to the profile will update all 20 machines or however many have the particular project as active.
Another thought: a BAM. WCG is not having it. Suggest you go into the preference screens of each client and select the Computing Preferences > Use Web Prefs. It should erase the local prefs... one source of possible conflict removed. |
||
|
|
Jim1348
Veteran Cruncher USA Joined: Jul 13, 2009 Post Count: 1066 Status: Offline Project Badges:
|
Suggest you go into the preference screens of each client and select the Computing Preferences > Use Web Prefs. It should erase the local prefs... one source of possible conflict removed. No, I want the local ones. The global ones are just that - global. When you change one, you change them all, which is not what I want. EDIT: I am now straightened out on another machine, the Ryzen 1700. When I request work with three days already in the buffer, I get this: 1629 World Community Grid 10/9/2019 1:16:20 PM Not requesting tasks: don't need (CPU: job cache full; NVIDIA GPU: ) The last machine (Ryzen 2700) I have just put on Rosetta. That is another way of dealing with it. So it seems that it straightens itself out eventually, though the cc_config.xml I used probably speeds it up, though I don't really know where the hangup was. [Edit 1 times, last edit by Jim1348 at Oct 9, 2019 5:21:06 PM] |
||
|
|
Jim1348
Veteran Cruncher USA Joined: Jul 13, 2009 Post Count: 1066 Status: Offline Project Badges:
|
I continue to have this problem intermittently on both my Ubuntu machines that run WCG, but not on any other project (yet). By "intermittent", I mean that sometimes WCG will stop downloading too much work and stick to the proper behavior, and then a few days later it will go berserk again and download 6 or 7 days work, until I stop it.
I am going back to 7.9.3, which is the repository version. |
||
|
|
|