That's a question for each project, not BOINC centrally.
It comes in two parts:
Does it need fast (valid results)?
(e.g. to generate dependent work, or to purge processed files from a small
server)
Can it cope with fast errors?
(does the demand for new work from a fast-erroring host cause
There are two possible outcomes from a broken host. First is a crash of
some sort. These can be picked up instantly on report. The second is a
validation failure. These cannot be picked up until after validation.
One possibility is to temporarily drop the quota on an undecided validation
Even so, it requires a BOINC mechanism, even if that mechanism can be
modified by flags at the server.
jm7
Richard
Haselgrove
Hi,
I read about Condor and they run boinc from a sched deamon on the worker
node. It is killed by a signal when real Condor jobs arrive, so this is
not an example of a batch jobs based boinc.
I tried several things, including
... --exit_when_idle --exit_after_finish
$ cat cc_config.xml
If it's a per-project question, then each project is going to have to
develop their own solution. The best BOINC can do is provide a few hooks.
... and if it has to be done per-project, then there isn't a whole lot
to discuss here.
The point I was trying to make is: what problem is this
A missed deadline has always been considered a failure, though of course
it's the failure with maximum latency. Also note the host punishment
terminology emerged first in the new credit design, so what we're discussing
here is sort of only applicable to SETI Beta now and other projects in
future.
How much benefit can be derived from faster detection of problem hosts
is certainly important, and I don't have enough data to make any
judgement. Any potential change of course ought to be subject to a
cost/benefit anasysis.
My guess is that the idea of a pre-validation check of each returned
So, based on this scenario... the user sees that MW work is downloaded that he
does not want ... so he continually resets the project and can circumvent the
project limits?
This is now the fourth possible scenario (though it sounds like the only one
tested) proposed ... we still have not come
On Fri, 28 May 2010 12:14:44 -0700, you wrote:
So, based on this scenario... the user sees that MW work is downloaded that he
does not want ... so he continually resets the project and can circumvent the
project limits?
This is now the fourth possible scenario (though it sounds like the only
On 5/28/2010 2:59 PM, Rattledagger wrote:
Don't point to the wrong problem, user manually resetting project very many
times is an unlikely scenario. While this does in some way generate
ghost-wu,
the most common reason for ghost-wu is due to connection-problem. If
scheduling-server gets a
10 matches
Mail list logo
