Messages

Yes, that would certainly work, particularly if I don't run BOINC as a service and prevent the BOINC client from automatically starting at system start.

Although I had hoped to avoid expanding the number of "control" processes beyond the three of the BOINC client and your quite useful BoincTasks and TThrottle, I appreciate your time and advice.  Since I rather prefer the "central control" model of BoincTasks, I will probably use a combination of rules and SysInternals products to control BOINC client startup and their respective cc_config.xml files rather than increase the distributed complexity by relying upon TaskManager on an individual basis across all of my systems. (With the caveat of "whatever it takes" to make Microsoft"Patch Tuesdays" and power events that outlast my UPS systems less traumatic).

Again, thank you for your time and advice.

I only run one project per system (with the exception that I might run a GPU project while CPU cores are devoted to a different project). 

And the subject has been raised with the project, but appears to be impossible to address due to the design of the project and the third-party software that it incorporates.

I thought it might be possible to tick the # of CPU cores allowed up at a set interval ("On multiprocessor systems, use a most X% of the processors").

CEP2 from World Community grid checkpoints...erratically.  As a Windows user, I have monthly "Patch Tuesdays" to worry about.  I  can't do anything about the computational time lost because of lack of control over checkpointing, but if BOINCTasks would permit a "staggered start-up" of the tasks in project 'Y'...

Or, more reasonably, if you could select a group of tasks and say "Pause these, and then resume them individually at 'X' minute intervals", I could avoid/reduce the performance hit from the synchronized I/O, I/O contention, and the consequential I/O waits for hard drive/RAID sets access.