Paul D. Buck wrote > Again, the point being that we still have the issue were BOINC > continually changes its mind about what should be running. > > One of the causes is that we call the schedulling routine so often. But > that is not all of it. Even if we do throttle the number of calls to > this routine it will not stop the switching because the deadline rules > are still skee-woof, but it will help reduce the onset slightly.
Again, I disagree. 'Request CPU reschedule'. doesn't (shouldn't) automatically mean that a change will happen - I snipped many occurrences from my logs where the result was NOP. 'Request CPU reschedule'.calls a TEST to see IF a reschedule is necessary/appropropriate. Jiggling with the number of times the test is run won't make the slightest difference if the test itself is flawed. I was intriqued by the "Idle state changed" case, because I see the effect on my P4/v5.10.13. Not every time, but enough to be noticeable. On this system, I've never noticed a timeslice run short - it's always been at least an hour, and then some. That suggests that on a slower, single-core, machine, 'Request CPU reschedule'.happens, if anything, too rarely. If there are no task exits, work fetches, or file downloads, then the TEST doesn't run. And it seems as if "Checkpoint reached" only triggers "Request enforce CPU schedule" - for the current schedule, presumably. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
