Christian:
Each scheduler RPC request includes a list of jobs on the client.
How about if we add the following optional scheduler feature:
enumerate the jobs assigned to the host,
and if any of them is not listed in the request,
assume it's been lost and create a new instance.
This doesn't handle the case where the user paused a job and forgot about it.
Does this case matter?
-- David
On 22-Nov-2013 11:13 AM, Christian Beer wrote:
Not when the task is lost because the user formated the harddrive or
paused the task and forgot about it. In those cases, where the user
doesn't cancel the task but it is not processed either, we would
generate a new task very late. This is not a desired behavior.
We could use the trickle up logic to abort the task server side if we
don't receive a trickle within 14 days but than we have to use a new
table or other structure to store the last trickle contact.
Am 22.11.2013 20:02, schrieb David Anderson:
Wouldn't this be equivalent to having an extremely long deadline to
begin with?
On 22-Nov-2013 4:50 AM, Christian Beer wrote:
Hi David,
maybe something else is possible. What if the server can mark the
deadline of the task as "non compulsive" so the client won't go into
high priority mode to keep the deadline. This would of course only be
suitable for projects that either increase the deadline using trickles
or don't care about the deadline at all.
Regards
Christian
Am 12.11.2013 06:00, schrieb David Anderson:
Christian:
Unfortunately, with the current architecture there's no easy way to
communicate
to the client that the deadline has changed.
-- David
On 11-Nov-2013 2:05 PM, Christian Beer wrote:
Some users reported that for our long running jobs the client switches
to High priority mode for RNA World and will not switch to other
projects as usual.
I currently have a task on my desktop with an estimation of 340 hours
with a 20 day deadline (that I can not meet with an uptime of 6h per
day). I don't want to increase the deadline for those long runners
because than we have to wait 2 months until a new task is created
because the first task vanished on the host. Sure this is the worst
case scenario but we are more flexible with a shorter deadline.
My fear is that users are aborting our tasks because they think they
missed the deadline or can't even meet the deadline. I see a lot of
EXIT_ABORTED_VIA_GUI with our new VM application. This maybe only be
fixed with an increased deadline but the problem of an underestimated
runtime can still occur and if the task is still running on the client
we want to know on the server. And the client should also know that
there is more time available to finish the task and there is no hurry.
Regards
Christian
Am 11.11.2013 22:28, schrieb David Anderson:
Thanks; I committed these.
Currently the deadline isn't changed on the client.
I'm not sure this really matters; what do you think?
-- David
On 11-Nov-2013 11:28 AM, Christian Beer wrote:
Hi David,
now that Trickles are working again I updated the trickle_deadline
handler. I changed the output to the BOINC format like in
scheduler.log
and added a hostid check to the result lookup for more security. Now
every host can only extend the own results and not others.
The code is tested on RNA World.
Regards
Christian
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
