On Apr 28, 2009, at 4:39 PM, Mikus Grinbergs wrote: > John wrote >> 1) What should we be working on if we did a task switch now? This >> detects >> that cases where we need to trigger a task switch immediately >> because of a >> potential missed deadline. > > I keep advocating 'scheduling across a span of time'. To my mind, > there are 100 hours to run these tasks before deadline. Take away > the interval-between-connects, and that leaves 70+ hours to complete > crunching of all of these tasks. Even if these tasks were run > sequentially, I would expect "scheduling" to conclude that they > could finish in less than two days - that is, *before* deadline. > > So why does "scheduling" think there is a potential missed deadline? > The only answer I can come up with is that "resource share" is being > factored in - if this is one of five projects, then 20% (they all > have equal shares) of 70 hours is 14 hours - not enough to do the > estimated 40 hours of work. But this is a four-core system -- so > 20% of (70 * 4) is 56 hours of crunching that this project is > "entitled" to in the next three days.
This is the kind of example that I called a "false positive" detection of a missed deadline. Though the running in high priority in reality changes nothing in the system, the fact that you may be running these tasks in parallel can lower system efficiency. My notes: 6) Resource Share is used in calculating run time allocations 7) Work "batches" (tasks with roughly similar deadlines) are not "bank teller queued" 8) History of work scheduling is not preserved and all deadlines are calculated fresh each invocation. 9) True deadline peril is rare, but "false positives" are common You have to consider some aspect of RS as a driver otherwise projects like CPDN would not get scheduled until the tasks were close to being at the deadline. The problem is as you have noted that if RS is small it can swamp other factors and throw the system into a tizzy. Particularly on "wide" systems this can be a significant issue. _______________________________________________ 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.
