Hi, just a short follow up from me on behalf of RNA World. I gave this a bit more thought and would also support the idea described in step 3 below. We haven't heard anything bad about the Client being in EDF mode because of RNA World but I think it's not fair to other projects to lock the resources of the volunteers for our project.
Almost everything needed for this is already in place. Changing the trickle_deadline handler to update another field or table is trivial. I can also add the logic of aborting or reactivating the task. The question is: do we add another field to the result table (last_contact) or create a new table for this. This shouldn't involve any scheduler changes but later on, this mechanism can be triggered by the scheduler too (when getting the result list via scheduler request). Regards Christian Am 25.11.2013 15:28, schrieb Michael Goetz: > 3) The app will be send a trickle-up message every day. By detecting that > a trickle hasn't been received in several days, the server could decide the > task is abandoned long before the deadline and send a new result out to > another host. This could result in extraneous results being sent out if a > host is offline for several days, but it could also result in much faster > cancellations of abandoned task. > > Now for the better idea: > > In theory, we could employ ONLY step 3 and use REALLY long deadline plus > this mechanism to allow slow computers while still avoiding huge delays > simply by using trickle ups to report status without needing to extend > deadlines. It's a simple server change: if you haven't received a trickle > up message showing progress on the task in N days, mark it as expired in > the database and a new task gets sent out. That effectively makes the > deadline (as it pertains to sending out a replacement task) fairly short, > whereas the deadline that affects how long a host has to finish could be > very long. For me, at least, this seems to have the same end result as > building a deadline-extension mechanism, but is much, much simpler. > > The only drawback of the simplified approach is that users who use app_info > and don't update to the new app that sends status trickles will "time-out" > prematurely and cause the server to send out unneeded tasks. > > Mike > _______________________________________________ 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.
