For the most part, sub second CPU throttling is a bit of a botheration
scheme -- and frankly BOINC's attempts to implement it at the middleware
level have not been a success at any level.
This feature was so undocumented on the client side -- that if one did turn
it on -- its odd behavior soon forced one to change back the parameter that
turned it on in the first place. There were no multi-screen prompts telling
one what one was doing when turning it off or on. It was like doing ALPHA
testing on a atterbrained CPU. Even CPU designers don't like to do this!
(See my "Climate Prediction CPU" PDF, if you are bored...)
This sub second CPU throttling feature should always be left up to the host
OS, as it causes the least confusion.
I understand that there is a desire to have this feature be used on
smartphones, iPads, etc ... but even in this execution environment it may be
too adventurous for the host OS on these platforms.
This sub second CPU throttling is more of something that an OS like
-- QNX
-- Minix3
-- VxWorks
might be suited for.
SO ... NOT A DESKTOP OS ... but RTOSes
Short of publishing a series of research papers begging for a solution in
IEEE / ACM / Wired / Wikipedia / ... there is no way this solution will ever
be implementable as there is no edge code for it. (And the edge code must be
unique for each OS!)
Admittedly, there are probably quite a few projects from the /etc/snowden
files that have the proper OS edge code to do this, but the existent
civilian code bases don't have anything that is workable or usable.
MP, sysadmin
DSN @ Home
--------------------------------------------------------------------------------
-----Original Message-----
From: David Anderson
We've been working for a while on "sub-second CPU throttling", in which the
suspend/resume cycle is 1 second (i.e. 20% CPU usage means .2 seconds on, .8
seconds off).
The goal is for tools like Windows Task Manager (which have a 1-sec sampling
period) to show a constant 20% usage, rather than jumping up and down.
This requires that apps be able to handle suspend/resume messages at that
rate. This is true for the BOINC API, which since 2007 has used a .1 sec
polling loop (i.e. it checks for suspend/resume messages 10 times a second).
However - and I just realized this, to my dismay - the BOINC wrapper has a 1
sec polling look, so it can't handle 2 requests per second.
It ends up either running or not running for long periods. Since the wrapper
is used by many projects, we have to put sub-second throttling on the back
burner for now. The next Alpha test release will have old-style CPU
throttling.
Long-term, there are various options:
[...]
2) Use operating system mechanisms for suspending/resuming groups of
processes that weren't available when we originally designed BOINC.
This would eliminate the need for the polling loop in apps.
3) Use OS features that do throttling for you. This would greatly simplify
things. However, such features don't exist in most OSs.
--------------------------------------------------------------------------------
_______________________________________________
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.
