On Apr 25, 2009, at 12:31 PM, John Keck wrote: > 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.
Thank you ... :) TSI, once an hour ... or task end .. but that is just me ... I guess my biggest mind boggle with this is the notion that we will be more likely to not miss a deadline if we run the tests once a minute or more often. Thus my notion that we need to rethink the resource scheduling... One thing to consider would be an "adaptive" resource scheduler where for the faster and wider systems we would be using almost exclusively EDF and bank teller rules... The older systems could continue to use the older system... Or, a more conservative migration approach might be to give us "early birds" a cc_config flag so we could test the new scheduler ... Quite simply put, all the tasks would be lined up in deadline order and we would pull them off and schedule them ... preemption would only be for task end or TSI ... new tasks would be pulled and run one by one. The only exception would be a task that was truly in deadline jeopardy ... thus we would eliminate the running of 6 IBERCIVIS tasks all at the same time because we D/L them at the same time. Likely they would be run serially on one CPU till the batch flowed through ... _______________________________________________ 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.
