Gilthanis
[H]ard|DCer of the Year - 2014
- Joined
- Jan 29, 2006
- Messages
- 8,765
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
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: