Paul D. Buck wrote: > On Apr 27, 2009, at 10:14 AM, [email protected] wrote: > >> As long as you insist on talking about the frequency of the test, >> people >> are going to be ignoring you. Please start talking about what is >> wrong >> with the test itself. Fixing the test will fix the problem. No
[...] > I agree that changing the frequency is not going to solve this, but > maybe it will allow me to help provide the data so we can solve the > rest of the problems. And changing the frequency of the tests will > make the system a little less unstable. Oh, and save compute time. > Oh, one more thing, running the test every 60 seconds with a 2 minute > task means I would still make the deadlines... no need to run the test > RIGHT NOW ... 30 seconds later would not be a killer ... even for a > mythical need ... I agree with both comments. Restricting the (time) frequency of the rescheduling will allow for some debug. Task thrashing detection could impose a reschedule delay just to keep the system stable and also issue a bug report of the circumstances so that the unstable scenario can be better accommodated. Enforce sanity checks on deadlines and transfers wrt to a host's past performance? What needs fixing is what are the triggers, tests, and what is rescheduled. Do we /really/ need to reschedule *everything* for each and every trigger event? The numbers from P D Buck and J Sanborn are sobering. "Even if the check takes only a fraction of a second, at some point there will be machines where at least one of it's processors will be hitting it all the time." Employ the linux O(0) scheduler?... Regards, Martin -- ---------------- Martin Lomas [email protected] ---------------- _______________________________________________ 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.
