I have to say, I don’t understand the end of race bunker. You generate the same score dropping at the end as you do with continuous production, and you risk not validating the entire bunker if you drop too much too late.
@Icecold answered this, but here are some more basic considerations:
Many Distributed Computing competitions are about getting as much work · credits/work as possible validated between the points in time T1 and T2. Among else, there are these four characteristic approaches a user can take:
/1/ Start computing at time T1, let the client report results until time T2.
/2/ Start computing before T1, let the client report results until T2.
/3/ Start computing before T1, let the client report results between T1 and T2.
/4/ Start computing before T1, report results at the latest opportunity between T1 and T2.
Given the same computational throughput, the final score achieved by these approaches is circa /1/ < /2/ < /3/ = /4/.
So far, so good. You already noted one risk at /4/ compared with /3/, and I add to this that /4/ generally requires more work, and deferred validation means deferred feedback to yourself on your performance. Not quite desirable.
However:
/1/ results in a deferred, then circa linear, production history.
/2/ results in a circa instant and circa linear production history.
/3/ results in an overall decelerating production history.
/4/ results in an overall accelerating production history.
Now let's assume for a moment that users cannot influence the performance of teams anymore after the start of the competition.
- What is more satisfactory, a competition in which all teams have circa constant production rate, or a competition in which some teams decelerate, other teams accelerate?
- In a competition between teams with constant, decelerating, or accelerating production, on which kind of team would you prefer to be?
Of course the answers will be subjective and differ between individuals.
But in reality, users
can influence teams performances still after the start of a competition.
- They always can reduce initially active computer capacity, thus save costs.
- Sometimes they are able to increase performance by optimization, which generally requires knowledge and skill and work.
- Sometimes they can activate initially unused computer capacity, thus increase cost but increase performance. This can be capacity they own, capacity owned by friends, or capacity which is for rent.
- They always can switch teams, thus improve performance of another team while removing performance of their former team.
Now, as
Icecold and
myself already pointed out, deferred validation does not only withhold information to yourself, but even more so to others. Having information early enough influences whether the above steps to influence teams performances are taken, and how successfully.
) Just like a lot of people bunker before the race, though, bunkering during the race to drop tasks at the end(to ideally surprise your competitor before they have time to react) is a totally acceptable practice done by a lot of teams, if not almost all.
Facebook
Twitter