WCG tips and strategies

Gilthanis

[H]ard|DCer of the Year - 2014
Joined
Jan 29, 2006
Messages
8,753
ChristianVirtual's request in the WCG recognition thread inspired this thread. I didn't really want to discuss it in open forums due to some of the tips not being always looked upon as fair.

Sometimes work units are hard to come by, are set to a lower priority, and are gobbled up as soon as they are sent to the hopper. It helps to have a few tricks up your sleeve. And as always, the more hands on your are the better off you will be of actually getting your fill.

HSTB and BETA work units are highly sought after at the moment. BETA almost always.

I recommend using VM's for this honestly. Set the VM's to use a profile like "home" , "work", or "school". Then set that profile to only pull BETA and HSTB. Make sure to uncheck the box that says send work if selected projects have no work. Be careful with profiles because if you change the "default" profile, it will change the other 3 to match it. Yes it is stupid like that but WCG has not fixed it otherwise.

Second thing I would do is set each VM to use the cc_config file.
<cc_config>
<options>
<ncpus>48</ncpus>
</options>
</cc_config>

48 is just an example for a 48 core machine. Change this number to however many cores you want BOINC to think you have. This means that regardless of how many CPU cores you assign to the VM... BOINC will try and download work based on how many CPU's you make it think you have. You can always change this back to something to match the VM after you get work.

You will want to do that on all the VM's because the more buckets you set out, the more rain you will catch. The clients will continue to back off each time it requests work and fails to the point of 24hours. So, you may need to manually update them every now and again or set up some scripting.

There is a thread at WCG about doing some of this and using task scheduler. https://www.worldcommunitygrid.org/forums/wcg/viewthread_thread,39670

Some people have used cron jobs in Linux to constantly ask for work.

The problem with asking for work too much is that it hammers WCG servers. The above linked thread talks about other user's experiences on times they have been most successful for getting work.
 
Some people may be concerned about idle cores by using the VM's in the manner above. However, you can still crunch on those threads either by letting other vm's have those cores (shared) or from the host client directly.

The other advantage to the cc_config file above is that if you are seeking BETA work, it will let you essentially bipass their limitation on number of BETA's downloaded per host. I believe it is one or two per core/thread.

I would also stagger the vm's being started up so that your clients are requesting work at different times unless you are using task scheduler to attempt specific times.

These tactics can be used elsewhere as well such as at NCI application projects. So, if you want to run Grid Computing Center (formely GoofyxGrid) then you could also use them to run additional instance to utilize the resources.

Another advantage is that if you want to run other projects, you can continue to request work for the desired WCG and the other projects won't impede calling for them.
 
I would just have to figure out how to convert a linux OS into a vhdx without loosing anything.
 
Actually I just did on the main profile ; no VM ... eventually I got a number assigned. Let see how long it last to reach one badge. Seems the priority for those HSTB is low compared to all other. Boinc can be work ...
 
Yes..they are set at a lower priority on the server so that people that choose multiple sub projects will get those allowing for more HSTB to go to those seeking only it.
 
Back
Top