If the user has paused a job, they should probably not get it replaced. If it is past deadline, and is still paused, then we might want to abort it. If it is paused and is in deadline trouble, then we might want to warn the user of the problem.
-----Original Message----- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David Anderson Sent: Friday, November 22, 2013 2:33 PM To: Christian Beer; BOINC Developers Mailing List Subject: Re: [boinc_dev] updates for trickle_deadline.cpp 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 boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
