Just to clarify.
The glitches in my example were caused by the commercial skip software I
have installed. It was configured to be able to process one recording
per processor until I figured out it was causing the glitches during
media playback. I have reconfigured since then to avoid the glitching
during media playback.
My preference would be something along the lines of:
Threshold = 25%
Avg1 = Last three seconds sampled
Avg2 = Last ten seconds sampled
If Avg1 > Threshold Then
Suspend
Suspended = true
End If
If Suspended && Avg2 < Threshold Then
Start
Suspended = false
End If
For the likes of Netflix and other streaming media services this will
work well because the app is getting the decryption keys, buffering, and
causing the system to switch into a different display mode.
----- Rom
-----Original Message-----
From: David Anderson [mailto:[email protected]]
Sent: Wednesday, February 17, 2010 1:52 PM
To: Rom Walton
Cc: Charlie Fenton; BOINC Developers Mailing List
Subject: Re: API suggestion to help in user retention
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.
