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.
