IIRC, that was put into place as part of a way to deal with high priority vs. lower priority items.
I don't remember if it was an internal hospital grid or some form of internal research grid, but the example that comes to mind is during the normal course of the grid's operation they process 10-20 minute tasks. Every once in awhile they have to plow through some high priority work, so they shorten the deadlines. For some reason processing MRI's comes to mind. I think the target goal was to have a complete turn-around for the high-priority tasks within 5 hours or something like that. I'm not sure if this scenario is accurate anymore. ----- Rom -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul D. Buck Sent: Saturday, April 25, 2009 9:13 PM To: TarotApprentice Cc: BOINC dev Subject: Re: [boinc_dev] 6.6.20 and work scheduling On Apr 25, 2009, at 5:30 PM, TarotApprentice wrote: >> Date: Sat, 25 Apr 2009 14:31:01 -0500 >> From: "John Keck" <[email protected]> >> Subject: Re: [boinc_dev] 6.6.20 and work scheduling >> To: "Paul D. Buck" <[email protected]>, "Richard Haselgrove" <[email protected] >> > >> Cc: BOINC Developers Mailing List <[email protected]>, >> John McLeod <[email protected]> >> Message-ID: <49ac83b79e5d462cbe9dc89290e34...@tsi5200w> >> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; >> reply-type=original >> >> I definitely agree with Paul; I don't see a good reason to test for >> a CPU >> reschedule more than once a minute and 5 to 10 minutes seems more >> reasonable >> with the exception of a resource going idle. In the best case we >> are wasting >> cycles that could be used by the science app. In the worst case we >> kill >> tasks that have trouble dealing with multiple stops and restarts. >> >> john > > I'd suggest: > a) Download finishes (more work has arrived - we need to check > deadlines) > b) Task completes (we have a free resource) > or if none of the above every 5 minutes The reason I keep questioning the download work check deadlines is that why might it be fatal if we don't check for even as long as an hour? This is the part I really don't get, what is changing so fast we have to check every 60 seconds. I just cannot see it. At TSI (default 60 minutes) or tasks end, sure, no problem ... Other than that, I am at a loss as to why one hour one way or another, one download or another, is so critical to make sudden changes. If work fetch is working correctly, we should not be that overburdened. If that is what we are protecting against, then the Work Fetch is broken because we are getting too much work in an unsustainable cycle. This is part and parcel why I was arguing, unsuccessfully, for an end- to-end re-thinking of what we are doing back a couple months ago when discussing the approaches for GPUs ... because we are going to have to do it sooner or later ... Right around the corner is ATI and OpenCL ... Larrabee (?) ... what next ... _______________________________________________ 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. _______________________________________________ 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.
