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: 1) Apps tell the client their poll period, and the client uses an appropriate throttling rate. This would be a medium change to the client, which currently throttles all apps together. 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. -- 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.
