Is there maybe some logic in the _linux_ (kernel?) scheduler that could be borrowed? J
On 17 Feb 2010, at 18:51, David Anderson wrote: > Right. So which policy do you think will work? > > Rom Walton wrote: >> The problem with the current policy is that it can be up to 9 seconds >> after somebody starts a movie before BOINC will suspend. >> >> That'll be 9 seconds of glitches for both audio and video in the >> worst >> case scenario. For the media center experience, it is easier to >> reboot >> the computer than to go get the keyboard and mouse to see what is >> going >> on. I don't run BOINC on the media center since it already has enough >> going on, however I do rebooted the media center when it glitches for >> more than 2 or 3 seconds. >> >> ----- Rom >> >> -----Original Message----- >> From: David Anderson [mailto:[email protected]] >> Sent: Wednesday, February 17, 2010 1:05 PM >> To: Rom Walton >> Cc: Charlie Fenton; BOINC Developers Mailing List >> Subject: Re: API suggestion to help in user retention >> >> >> Rom Walton wrote: >>> It seems to me that it would be better to monitor this once a second >> and >>> then use a decaying average to prevent needlessly starting and >> stopping >>> processes for apps that jump around the user defined threshold. >> >> I'm not sure what you mean by "needless". >> If the load average is close to threshold, >> BOINC should stop until it's well below threshold. >> >> The current policy is: >> every 10 seconds, look at CPU usage over the last 10 sec. >> If it's greater than 25%, suspend BOINC; otherwise, resume BOINC. >> >> Suppose there's some activity that uses 100% of the CPU >> for 1 second, every 5 seconds. >> The current mechanism won't trigger. >> >> a) We could make it trigger by sampling every 1 sec. >> Then, on average, BOINC would suspend itself halfway >> through every spike. >> >> b) Or we could be more aggressive: sample every 1 sec, >> and if CPU load is above 25%, suspend BOINC for the next 10 sec. >> This would keep BOINC suspended indefinitely while >> that activity is going on. >> >> We need to do some experimentation with real apps >> (e.g. video playback, commercial-removing software) >> to decide whether to use a) or b), and what the parameters should be. >> Maybe what we should do is provide detailed controls via >> cc_config.xml, >> and let people experiment. >> >> -- David > > _______________________________________________ > 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.
