No OS except recent Linux has a static priority scheduling policy.

On 04-Aug-2010 7:38 AM, Nicolás Alvarez wrote:
> Isn't this the job of the operating system's process scheduler?
>
> Enviado desde mi iPod
>
> El 04/08/2010, a las 00:28, David Anderson <[email protected]>
> escribió:
>
>> The suggestion is:
>> if the non-BOINC CPU load on a 4-CPU system is 25%,
>> BOINC should use only 3 CPUs.
>> Seems reasonable to me.
>> Comments?
>> -- David
>>
>> -------- Original Message --------
>> Subject: RE: Enhancement suggestion: CPU Usage exceeds parameter
>> Date: Tue, 3 Aug 2010 20:57:43 -0400
>> From: Sean White <[email protected]>
>> To: 'David Anderson' <[email protected]>
>>
>> I though NCPU's was not the % of CPU's, but the number BIONC was
>> allowed to
>> use? In the parameters panel - this is listed as % of processors - so if
>> this is the units, then your expression makes sense. How would you mange
>> the current 'over allocation' allowed which allows you to fully task the
>> CPU's as well as GPU's? Or -- if the over allocation is A, then BIONC
>> would
>> allow for peak processor usage to spike to NCPU's-X+A, and continue to
>> push?
>>
>>
>> The reason for a more involved process would be to attempt to detect when
>> the user or another pre-scheduled task is actually using the computer
>> (i.e.
>> gaming, watching a video, video recording etc) where the user
>> experience or
>> task is often time sensitive and may peak to higher usage levels. The
>> more
>> complicated approach assumes that the only tasks running on the computer
>> that would consume any significant fraction of a single CPU's time are
>> 'critical' or 'important' tasks. Assuming that there is some element of
>> time-criticality to any of these means that BIONC would need to back off
>> further than just "x" to give sufficent room as to minimize the time
>> critical impact. I suppose that this could be done by monitoring both the
>> average non-BIONC CPU usage over a period as well as the Standard
>> deviation
>> of the CPU usage. If the average is over a threshold (configurable?) then
>> BIONC scales back by X + 2 Standard Deviations to ensure that overhead is
>> available proportional to the peak processor usage over a period. If the
>> average usage is below the threshold, the 'noise' is ignored.
>>
>> -Sean.
>>
>>
>>
>>
>> -----Original Message-----
>> From: David Anderson [mailto:[email protected]]
>> Sent: Monday, August 02, 2010 7:09 PM
>> To: Sean White
>> Cc: BOINC Developers Mailing List
>> Subject: Re: Enhancement suggestion: CPU Usage exceeds parameter
>>
>> That's a good idea.
>> I'd been thinking about something similar.
>> What I was thinking was to eliminate the preference,
>> and just change things so that if non-BOINC CPU usage is X,
>> BOINC will use at most NCPUs - X.
>> -- David
>>
>> On 26-Jul-2010 2:37 PM, Sean White wrote:
>>> David,
>>>
>>>
>>> I've been a longtime BIONC fan, and had an 'enhancement' suggestion with
>>> respect to the 'cpu usuage' exceeds 'parameter' feature. Instead of
>>> shutting down the entire set of processess when the cpu usage exceeds a
>>> threshold, it would make more sense to roll back usage 1 CPU at a time.
>>>
>>> If a computer has Y CPU's available for use, and the 'other process
>>> usage' parameter is set to value X, then when Non-BIONC Usage /Y > X for
>>> a minimum time interval 'T', then we freeze one BIONC process, freeing 1
>>> CPU to manage the non-BIONC tasks. The next trip occurs when Non-BIONC
>>> usage / Y > (1/Y+X). (I.e. when the non-BIONC tasks load up the 1 CPU
>>> and start impinging on the 2^nd CPU, we drop the second CPU out). I
>>> would suggest that a reasonable 'drop out time' is 1s or so? (whatever
>>> is currently used).
>>>
>>> This approach would eliminate the annoying 'entire BIONC all tasks
>>> offline' event which I encounter when multiple tasks happen to end at
>>> the same time, or when you open another application that happens to need
>>> all of 1 CPU briefly to get going.
>>>
>>> Cheers,
>>>
>>>
>>> Sean W.
>>>
>>
>> _______________________________________________
>> 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.

Reply via email to