Bunkering - Why you should or should not do it

Gilthanis

[H]ard|DCer of the Year - 2014
Joined
Jan 29, 2006
Messages
8,718
First I want to say that this thread is not me preaching or trying to influence in any way. It is merely an attempt to describe the tactic and process as well as giving clear insight to what it does and how people perceive it. It is up to each person to decide if they want to employ the tactic and whether they agree with it or not. [H] has no official stance on the matter.

Bunkering is a term used in BOINC challenges that don't monitor when work units were sent in regards to the start time of the challenge. How it works is that before the challenge, you increase your cache within BOINC settings to download a large number of days worth of work. Then you disable network communication so that it does NOT report work back to the server. Then when the challenge begins, you turn your network communications back on and dump a ton of work all at once on the first day.

So, what you would do is plan ahead for the challenge. Since BOINC will let you cache up to 10 days worth of work, you will want to start your bunkering 10 days (possibly a little less to give room for error) before it. This way, when the challenge starts and you activate your networking again, you will dump an additional 10 days (or however many you cached up) to be tallied during the challenge. Unless you want to have a constant cache of work, you would also want to change your cache settings back to the normal amount before turning your network communication back on.

There is a second use for bunkering. If the challenge is at a project that has scarce work, bunkering can be used to prevent other teams from downloading enough to keep them busy. The tactic is deployed while work is available and you suck up a full 10 days worth of work. This tactic can even be deployed when there is less than 10 days left in the challenge. So, even if those points aren't tallied during the challenge, you will in essence be preventing other teams from getting those points.

A lot of teams "bunker" during challenges. This does not mean the entire team does it. However, some will encourage the behavior because it gives them a leg up on the challenge. Some projects wont need the work back immediately, and therefore do not mind getting the results back in such a way. With advanced warning, they can even prepare for the behavior.

This brings to question "Why wouldn't you want to bunker?" Well, bunkering is a selfish tactic that only benefits the competition. Bunkering theoretically hurts the project. Think of it from the projects perspective. You send out work that needs done and someone deliberately withholds those results until a later date for the shear "fun" of it. That is right. People bunkering are actually retarding the projects research. What if those work units were the cure to a disease? What if you postponing their analysis prevented someone from having that cure. Too bad we don't see the real world cause and effects.

The second thing it does is put more strain on project servers. Some projects continue to create work as their is demand. If people are vacuuming up work, this will require a lot more space for hosting results that could have been removed from the database. This raises operational costs. You also bog their network down with large uploads that normally the project doesn't have to deal with. Since there is already a challenge going on, their servers are already taxed. Now you have a couple hundred or maybe thousand users bunkering 10+ times the uploads all at once.

Now, some people see this as an extremist point of view. Some would argue the scientists will wait for an entire batch to be completed before analyzing it anyway. The truth is that nobody really knows nor will they ever know if "bunkering" is bad or not. So, make your own judgement call and most of all Crunch On!

Bunkering techniques in post 9
 
Last edited:
Doesn't every unit have a return deadline, regardless of the challenge?

We're talking about couple weeks at most and I'll risk a statement that extra boost resulting
from a challenge easily compensates two week delay (and then some!)...

Cunning, I love it.
 
Doesn't every unit have a return deadline, regardless of the challenge?

We're talking about couple weeks at most and I'll risk a statement that extra boost resulting
from a challenge easily compensates two week delay (and then some!)...

Cunning, I love it.

They do, but some projects like GPUGrid will actually want them back quicker sometimes. I know I have had many work units that got canceled because they were in a hurry and sent out new ones. Then there are projects like PrimeGrid whom get credit for locating results that others may also be searching for. Whoever gets them first gets credit for it. It is just a case by case scenario.
 
This falls into to the "don't ask, don't tell" category to me, although it would probably be easier to spot "bunkerers" once a challenge starts. Which brings me to my anti-Chimp Challenge rant that these unofficial challenges are a waste of time at best and disruptive to DC teams more typically.
 
Wasn't requirement to contribute under specific name/handle the main problem with CC?

BOINC challenges aren't like that... the more resources you bring the better for your team's
score (in given challenge).
 
Wasn't requirement to contribute under specific name/handle the main problem with CC?

I think so, although the real problem happened before I joined the team.

BOINC challenges aren't like that... the more resources you bring the better for your team's
score (in given challenge).

Or, the more you "bunker" results, the better your team's score will be.

I really don't care what we do - I am not involved enough to matter, so I will duck out of the conversation.
 
I think so, although the real problem happened before I joined the team

Ah yes, Chimp Challenge. IIRC the big problem had to do with the hassle of switching a folding farm to the CC Team Name and number. So, understandably, there were a few "heavy hitters" that did not participate which resulted in them being called out by a few folks. I'm not sure if it was all done in jest but it caused enough animosity to end our participation in the CC.

That was the first and last time I was in the CC with [H].
 
Bunkering techniques
1. Filling your cache within the BOINC client up to an additional 10 days worth of work depending on how many days you have until the challenge. Note: Some projects limit the amount of work you can pull to where you will not be able to get a full 10 days worth. Other methods may need to be used to pull additional work. Suspend your network connection by clicking Options, and then click Suspend network activity. When the challenge begins, wait an hour. Then click on Options, and then click on Network activity always. (or you can choose to run based on preferences)
2. If filling your cache isn't enough due to project limitations, you may need to resort to some trickery. If you set up a cc_config.xml file and place it in your C:\ProgramData\BOINC\ (if using Windows Vista or newer). Linux may have a few possibilities but if using the version of BONC from the repository, it might be at /var/lib/boinc-client. However, you may need to change the rights on the folder in order to edit the file. The file should include the following:
<cc_config>
<options>
<ncpus>48</ncpus>
<start_delay>30</start_delay>
<use_all_gpus>1</use_all_gpus>
<report_results_immediately>1</report_results_immediately>
</options>
</cc_config>
Change ncpus to whatever number of cores you want BOINC to claim the system has. You are essentially fibbing about how many cores you have by changing it to some crazy high. Be careful because BOINC will also try to start up this many work units while you are pulling work. I have noticed that if I tell the BOINC Manager to leave a core or two unused, that the system remains manageable. YMMV
The start delay is just to give you time to suspend BOINC in case you need to make changes before the system starts all of the work up. This is helpful if certain work units or configurations bring your system to a halt.
Use all GPU's simply is telling BOINC Manager it can use all of your GPU's. This does not mean it actually uses them as other settings may bipass it.
Reporting results immediately basically makes the client report when the work finishes rather than waiting for its normal check in.
Before applying the config file, make sure that any project you aren't wanting to load work up for is set to No New Tasks.
To tell BOINC to read the config file you can either completely close BOINC Manager and start it again or you can go in the Advanced View, click Options, and then click on Read config files.
Now just change your cache size accordingly and pull as much work as you can. Once you have your full amount, change your cache back to normal size and remove the ncpus line from your cc_config.xml file. Click Options, click Read config files to get BOINC to see your normal CPU's again.
Once you have all of the work units you need, within BOINC advanced view click on Activity, click Suspend network activity. This will prevent finished work from reporting. When the challenge begins, wait about an hour. Then click on Activity, click Network activity always (or based on preferences) to give BOINC access all the time and it will upload everything and start pulling new work.
3. You can run virtual machines on your system setting them to pull a full cache using the same tactics above.
4. You can dual boot. Running multiple OS's from the same PC. This can be tricky as sometimes the host gets detected the same and it causes havoc with pulling work. I don't recommend this method.
5. You can run multiple clients with BOINC. I do not have a good how-to on this one and it can be quite the pain to get set up. But some find running multiple clients a better way to go as they can limit the network activity to each individual client rather than to the whole thing.
6. If you are bunkering work for a CPU project but want your GPU's to continue to pull and report work from other projects or vice versa, you can try editing your hosts file within Windows. An example would be:
127.0.0.1 localhost

::1 localhost

127.0.0.1 www.cosmologyathome.org

127.0.0.1 www.worldcommunitygrid.org

127.0.0.1 scheduler.worldcommunitygrid.org

127.0.0.1 swift.worldcommunitygrid.org

127.0.0.1 grid.worldcommunitygrid.org

and you can find your hosts file at: C:\Windows\System32\drivers\etc

Or Linux
Linux
  • Open a terminal window.
  • Open the hosts file in a text editor (you can use any text editor) by typing the following line: sudo nano /etc/hosts.
  • Enter your domain user password.
  • Make the necessary changes to the file.
  • Press Control-x.
  • When asked if you want to save your changes, answer y.
7. If you have a lot of hosts and don't want to edit the hosts file on each one, you could block the project IP addresses in your Router's firewall instead. WCG's new site can be easily ping'd and is at 169.47.63.74. Just block traffic to and from that site until you are ready to drop the bunker. However, this may block you from viewing their site as well.
 
Last edited:
It's best to just use IPTables in Linux to block the IP.

Type this in shell to block the IP:
iptables -A INPUT -s 169.47.63.74 -j DROP

Then type this to remove it
iptables -D INPUT -s 169.47.63.74 -j DROP

No need to edit any files or run any additional commands.
 
It's best to just use IPTables in Linux to block the IP.

Type this in shell to block the IP:
iptables -A INPUT -s 169.47.63.74 -j DROP

Then type this to remove it
iptables -D INPUT -s 169.47.63.74 -j DROP

No need to edit any files or run any additional commands.


What if we don't use Linux? My netsh is not the best.
I am wondering about possibility of bunkering the windows boxen.
The question becomes, could one use windows task scheduler to block connection and enable connection on desired date? There is no QRB from my understanding.

We can create some rules:
netsh advfirewall firewall add rule name="Block from BOINC" dir=in interface=any action=block remoteip=169.47.63.74/32
netsh advfirewall firewall add rule name="Allow from BOINC" dir=in action=allow protocol=ANY remoteip=169.47.63.74/32

We can toggle some rules:
run, netsh advfirewall firewall set rule name="Block from BOINC" new enable=yes
run, netsh advfirewall firewall set rule name="Allow from BOINC" new enable=no

run, netsh advfirewall firewall set rule name="Allow from BOINC" new enable=yes
run, netsh advfirewall firewall set rule name="Block from BOINC" new enable=no

Additionally, I guess I could iptables at the router...
 
Yes you can use the Windows firewall, but it's only necessary if you want to allow other projects to run. I only do it on my Windows boxes because I run GPU tasks on them and can't get enough tasks queued to keep them busy for a long time.

You could just use the BOINC manager to suspend networking if WCG is the only project you are running.

I also use IPTables on my router to block WCG once I have ALL my boxen loaded with WCG. That way I can easily restore networking to them remotely.
 
I have done bunkering this year with a combination of boinc network activities and multiple clients to get GPU bunkering for Seti ; it was a real PITA to look after those clients and need some good bookkeeping to not loose some (and check when they are done to get new WU in a new client) ... WCG bunkering I’m just with with boinc client
 
Back
Top