This is windows scripting host script(in JScript), meant to be used for "dynamically" switch active GPUs in BOINC. It works in following way: uses MS XML COM object to modify cc_config.xml in appropriate way, then shutdowns BOINC core client(boinc.exe) with help of boinccmd.exe and start the client again, while BOINC Manager stays on. All operations are performed with single double-click on shortcut. Doesn't need additional software to be installed.
How to use it:
0. Ensure u have cc_config.xml file in your Data directory with at least following content:

<cc_config>
<options>
</options>
</cc_config>

1.Copy GPUSwitch.js in your BOINC Data directory(where cc_config.xml is).
2.Create number of shortcuts, according to your needs(Explanation follows).
2a.Create shortcut(s) to the script file and place it wherever u like it. e.g on desktop. Target should look like this:

"D:\Sensitive data programs\BOINC\Data\GPUSwitch.js"

Note the quotes when the path to file contains spaces.
"Start in" field must contain path to Data directory in same manner as above.
2b. Add additional parameters after script name(but outside quotes if they are present). Parameters are:
/i:x,y,z - where x, y and z are indexes of GPUs. E.g if u want to disable GPU 0, add /i:0, if u want to disable 1,2,4(assuming u have 5 or more GPUs) add /i:1,2,4 and so on. Any other values after semicolon or lack of characters will enable all GPUs. U will get notice about this with option to cancel operation.
/s - parameter suppresses above mentioned notice. If u use only this parameter and no /i parameter, script will silently enable all GPUs, removing ignore_cuda_dev entries for cc_config.xml.
And finally, command in Target field should look like this:

for disabling GPU 0 and 1:

"D:\Sensitive data programs\BOINC\Data\GPUSwitch.js" /i:0,1

for enabling all GPUs:

"D:\Sensitive data programs\BOINC\Data\GPUSwitch.js" /s

or

"D:\Sensitive data programs\BOINC\Data\GPUSwitch.js" /s /i

Keep in mind, parameter /s must precedes parameter /i (I leave it in this way to simplify parameter parsing, just simple rule to obey).
If u start script with no parameters it will be unhappy, will tell u some not very polite things and will exit. So parameters are a must.
3. Open GPUSwitch.js file, using any text editor, e.g Notepad(just be cautious using other editors - file must NOT be saved as Unicode text).
You will see following 4 variables almost on the top of the file:

var targetFile = "cc_config.xml";
var strBOINCDir = "D:\\Sensitive data programs\\BOINC";
var strGUIRPCpasswd = "a24ab662ab245ba245eb270bc7e7c9fd";
var strHost = "127.0.0.1";
var uDelay = 5000;

They need to be changed, or at least some of them, according to you setup. First, obviously is name of target file. We assume u don't need to change it. Second one is path to BOINC main directory(not Data directory, script is already there and does not need to know the path) in order to be able to use boinccmd.exe and boinc.exe(NOTE DOUBLE BACKSLASH PATH!!!). Third variable is your GUI RPC password, located in gui_rpc_auth.cfg file in BOINC Data directory(it may get automated too, but I decided to leave it to be added manually). Forth variable is host IP. Leave it as it is for localhost(script wont work on remote systems anyway, but I left is as parametric variable for future extends). Fifth variable is delay, in milliseconds between shutdown of core client and starting it again. It is needed, bcs core client needs some time to shut down. If it is not shut down, it won't start again. U can adjust this delay up or down, whichever suits u best. I picked up relatively high, but save value. The real delay needed may be very depending on the projects u run, number of client running overall host speed, current load etc. So, experiment with it, if doesn't work well(which means - client wont start after being shut down).
In conclusion u MUST change second and third parameter and probably u may need to change last variable.
4. Wait for units to come and test it :) :) :) I got lucky to get some bunch of resends just after I solved the problem with client detaching from console window. It works for me great.

I tried to find more elegant way to restart the client, but best achieved was to shutdown it thru RPC(via socket), and in PHP, bcs I was unable to find COM object allowing me to use sockets(well, there is one, but its functions need parameters passed by reference, which is impossible with JScript). I rewrote the script in PHP also, planning to use it as ActiveScript, bcs PHP does have sockets API, but I stuck in obstacle too - when PHP script is invoked with wscript, any COM instantiation makes the script to blow(generates exceptions and invokes my debugger). So JScript with external program call was most simple and most achievable way. It show console window twice, but its not that big PITA, as it actually saves file renaming or manual XML editing efforts.
I tested this on XP x86 SP3, XP x64 SP2 and Windows 2003 R2 SP2 x64.
A I write this, I realized, script is intended to be used when BOINC Manager is running. If u dont want stop/start operations of BOINC core client to executed, just remove those last three lines in GPUSwitch.js file:

WSHShell.Exec('"' + strBOINCDir + '\\boinccmd.exe" --host ' + strHost + ' --passwd ' + strGUIRPCpasswd + ' --quit');
WScript.Sleep(uDelay);
WSHShell.Exec('"' + strBOINCDir + '\\boinc" --redirectio --detach');

Download initial release from here.

Here is how it looks like on one of my rigs:


I will extend the script further to detect is the Manager running in order to execute stop/start sequence or not.

Happy crunching!

Nick

---

I'm assuming you'd do this if you have multiple GPU's and actually used that computer for daily use. I'm not sure how many crunchers actually use their multi GPU PC's like that.

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

So, u mean it is unnecessary to share it or...?
Numbers don't agree with u. It has been downloaded 200+ times already.

---

So, u mean it is unnecessary to share it or...?
Numbers don't agree with u. It has been downloaded 200+ times already.

I do not see the sense in it.. why not just suspend gpu while in use if that is an issue? Or manually suspend on demand?

Two clicks manual, none auto.

---

Janice

Bcs if u have, particulary, something different than Fermi based, u won't be happy watching videoclips, while GPU is crunching(its jerky). If it happens this video being longer, lets say 10-15 minutes, in BOINC, u have options to disable all GPUs. This means all except the first(playing video) will be idle. And it eternity for 2-3 GPUs GT200 class being idle that long.

I, for example, like to play time to time, Civilization 5 lately, and its quite annoying to modify cc_config several times a day. Lets say, I work 6-7 hours and play 4 hours, mixed. Which one to choose?
1. My second GPU(third, forth and so on) being idle 4 hours(while playing on first), bcs I turned GPU computation off, or snoozed GPUs from BOINC.
2. I get jerky game, perhaps some WU will error out bcs no memory. This illustrates case if I keep all them running with SETI(and not only SETI).
3. Or in worst case - 2 h work, 1 h play, 2 h work, 1 h play, 2 h work, 1 h play or something like this, I'll have to modify cc_config or swap it manually with other file, roughly 7 times? And all these efforts for saving above mentioned 4 hours crunching on second(third, forth etc) GPU.
Script will cost me 10 clicks(according to above example)to get my extra GPUs busy + anything else playing smoothly.

Gimme better options.

I don't get it. If u find this script pointless, why don't u just skip the thread?

---

You're right about that, but if you have 2, 3 or 4 cards, you can choose
which to use for CUDA, for example 1, 2 and 3 and if you also your graphics displayed, you use nr4 for your monitor, so you will have
no lag other other more disturbing screen distorsions, it's handy.

In BOINC you can temporarely disable GPU and CPU (+GPU).
All or nothing and that's a waiste, unless you use SLI, but then you can't use it for CUDA.

My CUDA (GTX480) host doesn't suffer from screenlag, but refuses to use 2 (different) card, a CAL/OpenCL rig (ATI 4850+5870) has such high memory load and
BUS-Trafic, that use of the screen is vveeeerrrryyy ssslllooowwww and 'windows aren't comleted, or the background is still the desktop.....(a bit) slow refreshing of the screen. (2seconds)

---

Its works here in this way:
I'm programming(Visual Studio, Dreamweaver etc) - all GPUs on full throttle(no lag on Fermi GPU, but scrolling the source is PITA if some older than Fermi GPU - I used to have 8800GTs beore. Same applies scrolling a page with many images in Firefox).
I decide to play
Click-click on my script(disable first GPU).
I play on first GPU, second is crunching.
Work time, game off.
Click-click(enable all GPUs).
All GPUs and Visual Studio on full throttle.
Friend sends me link with high def video - lets say, some MSDN Channel 9 presentation, 45 minutes.
Click-click(disable first GPU to have smooth video)
Watch Mark Russinovich on Channel 9 speaking of Windows 8 kernel. Second GPU is crunching in the shadows.
Click-click(enable all GPUs) and Visual Studio on full throttle again.
Gaming cycle and video cycle can repeat several times a day(I work at home, so no one can tell me what to do). Each "cycle" costs at least two times cc_config edit/swap. Or cost no edit/swap(in case I disable GPUs from BOINC), but my usefull GPUs other than first(it is either doing a game or video) sit idle.

or another separate example, with no games and videos:
Lunch takes and hour, lets say. I like keeping GPUs busy while I'm not at PC, even for an hour. Lets say also, when I'm working, I usually keep first GPU ignored(happens to me if I draw/paint complex graphics in Corel Graphics Suite). So, to keep the crunching pace tight, before getting to lunch, I have to edit cc_config to enable all GPUs, and getting back from lunch, I have to edit it again, to ignore first(desktop GPU). Those two manual edits I avoid with my script.
And there are many more reasons to leave PC for an hour.

I hope you got it now.

---

I never said that it was a bad idea. I thought it should be made clear that this is for people with multiple GPU's onboard. Single GPU users like myself already have the GPU snooze available Also I pointed out that the majority of multiGPU users don't use that PC for everyday use. I may be wrong but I think its a reasonable assumption that people running 4 or 5 PC's with MultiGPU setups that they probably have another PC that they use for gaming, watching video etc

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

I still do not get it. Just suspend it,(it comes back on after about an hour and a half) or have it auto suspend while you are using the computer. Pick how long.

So... why would you need a script?

---

Janice

I still do not get it. Just suspend it,(it comes back on after about an hour and a half) or have it auto suspend while you are using the computer. Pick how long.

So... why would you need a script?

Reread the above and stick a 2nd GPU in one of your setups, I'm sure that you'll work it out. ;)

Cheers.

---

You write the script for yourself and give it out free to be used by advanced users so I'm not complaining.
(I downloaded the script just of curiosity to see how it's written - I can't use it - I have no modern GPUs to be used for computing)

Just a few things (you know them for certain) which can make the script more user friendly for a non-programmer
(which don't feel comfortable editing scripts):


1) If it's possible for a JScript to read the registry you can get both BOINC dirs automatically:

[HKEY_LOCAL_MACHINE\Software\Space Sciences Laboratory, U.C. Berkeley\BOINC Setup]
"INSTALLDIR"="D:\\Programs.98\\Science\\BOINC\\"
"DATADIR"="D:\\Programs.98\\Science\\BOINC-Data\\"

( so it will be no need for the script file to be in BOINC Data dir
and no need for the line:
var strBOINCDir = "D:\\Sensitive data programs\\BOINC";
)


2) You say "it may get automated too, but I decided to leave it to be added manually":
var strGUIRPCpasswd = "a24ab662ab245ba245eb270bc7e7c9fd";
- but it will be better if the script get it from gui_rpc_auth.cfg

(the purpose of your script is to avoid manual editing of cc_config.xml
but people will need to edit the script every time you release new version)


3) If cc_config.xml do not exist - create it (containing the 4 lines you posted)


4) Check that the script runs in BOINC Data dir by existence (or absence) of client_state.xml


5) Instead of just:

if(oArguments.length == 0){
	WScript.Echo("No arguments given.");
	WScript.Quit();
}

... present some help. e.g.:

if(oArguments.length == 0){
	WScript.Echo("No arguments given. (No changes to cc_config.xml will be made)");
	WScript.Echo("Use on the command line:");
	WScript.Echo("/i:0    to Disable GPU #0");
	WScript.Echo("/i:1    to Disable GPU #1");
	WScript.Echo("/i:1,2  to Disable GPUs #1 and #2");
	WScript.Echo("/s      to Enable All GPUs");
	WScript.Echo("/d:5000 to set Delay of 5 sec before restart of BOINC core client (boinc.exe)");
	WScript.Echo("/n      to Not restart BOINC core client (boinc.exe) (you have to restart it manually)");
	WScript.Quit();
}

(I don't write JScripts and don't know if multiple WScript.Echo() have to be used or one with e.g. "XXX\n YYY\n ..." for string (text) to be shown on multiple lines)


6) Make backup of cc_config.xml before any changes are made.

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Very good points. I had some of them under consideration, but there are reasons I didnt make them in flesh:
1) There are some complications if u run 32-bit version of BOINC on 64-bit system. Registry entries for 32-bit programs are kept in separate branch, so I need to know what the case is. I can examine the executable itself, is it 32 or 64-bit, but I again need to know where it is. I decided to keep it simple - this path needs to be edited only once per host(likely on only one host, the one used for doing other than crunching, stuff).
2) Maybe I'll do it, but it will complicate things if u need to use for remotely controlling remote host(well, not likely, tbh). Its vital anyway. I use "maybe" twice in purpose, explanation is at the end. saving user's time when new version is out, is good. Point taken.
3) Sure, I considered this too. No excuse for me :)
4) It not possible to have definitive answer is it BOINC directory or not. I can, if cc_config.xml exists to assume its BOINC Data directory, but is add complications to the script also. User just need to place it there and it saves lots machine cycles. Its simple to understand and simple to do. I'll leave it in this way.
5) Help message I considered too, but I didn't want to present it, bcs for the moments parameters are only two. I see u added those variables as parameters. I considered adding them too, but knowing how annoying it is to edit shortcuts, I decided to keep it simple again. All those variables contain common data, not intended to be changed depending n script behavior and again in sake of simplicity and common use, I left it as variables. Parameter /n is good point, but I realized need of it in the time I posted announce post. I'll add it(maybe).
Single Echo call will do. Each Echo shows separate message, so it will be single Echo, with line break characters. Thats not an issue generally.
6) Good point, I didn't have it under consideration. Will do.

All "maybe"-s are because I work on native executable version(.exe program) of all this this, with GUI, profiles etc, which will make the script poinless(it is intended as temporary solution anyway, but probably will turn into useless solution if we don't get WUs soon :) ). GUI RPC automation, creation of cc_config if non-existent, and backup are three things I'll make for sure.

Thank you!

Изядоха ме с дрехите тези :) Пиши ми на лично да ти дам Скайпа си. Ако искаш, разбира се.
Поздрави и приятен ден!
Николай

---

...There are some complications if u run 32-bit version of BOINC on 64-bit system. Registry entries for 32-bit programs are kept in separate branch, so I need to know what the case is. ...

It is intricate, due to some different behaviour in older versions of Windows. I can provide you with the registry hueristic the Lunatics' Installers use if you need. I'm not suggesting that it's perfect, but works well enough to give you some guide.

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Thanks, Jason. I think I can tackle it myself, but perhaps u know something I don't. My greatest concern was that I can't test it on every Windows version in use around. It led me to the simpliest, but working 100% solution. I'll PM you my e-mail for those heuristics. They can make good use in this native program I write. It does uses registry to know where BOINC stuff is. Anyway, there are cases, where BOINC is not installed, just copied over, so way of manual modification is always a good option to have.
Thanks again.

---

This graphic shows clearly my point about using such script.

Top two lines show example of daily usage of GPUs when all they are turned off/on. Thick lines is when GPUs are crunching.

Bottom two lines are same, but it assumes only first GPU is being turn off when needed with editing cc_config.xml.

Red dots visualize points where cc_config needs to be edited and client restarted.
It clearly visible case 2 gives u 9 hours more crunching from second card for doubtful pleasure to edit/swap 10 times cc_config(s).

My script is meant to remove "doubtful" part from "doubtful pleasure". It saves u from all those edit/swap operations, but gives u more FPOs executed. Speaking in more numbers, 9 hours on 470 mean:
Average WU is 8 minutes, 100 credits.
540 minutes/8 ~ 68 units * 100 = 6800 credits.
If there are more than only two GPUs, this extends arithmetically. Losses are unbearable :) :)

I couldn't make it more clear and simple than this, tho.

Offtopic, but needs response(maybe its better to start separate thread):
As of how ppl use their multi-GPU rigs. Its about of point of view. If some ppl dedicate multi-GPU computers to the crunching, I dedicate free time of my multi-GPU computers to crunching. I mean, my computers is not multi-GPU for sole purposes ot crunching. They are meant for other work and crunch meanwhile, only when turned on(working) bcs other needs. And its pragmatical way of usage, thus most common way to be seen. In fact WHOLE dedicated computer ONLY for crunching, wasting my own resources, I find pointless. But is personal opinion, feeling and money too.
So argument "... how many crunchers actually use their multi GPU PC's like that(daily use)" makes no sense to me, sorry, they being majority or not(hard to prove in any direction). Multi-GPU PC is same common PC, nothing exceptional or black box, not to be touched. As being powerfull by default, they can serve daily tasks even better, without having dedicated to daily tasks computer.

---

Here is a new version, with all suggestions implemented and some other things added, except finding BOINC directory automatically.

The differences of usage as following:
1. You don't need to create cc_config.xml, of it doesn't exist.
2. It finds GUI RPC password alone.(u may override it by adding the the password in variable strGUIRPCpasswd as it was before).
3. Added argument usage massage, if script is started with no arguments.
4. It makes backup of config file(can be overridden with internal parameter).
5. It has 5 behaviors of restarting BOINC. See bellow for details. It was done, bcs BOINC Manager sometimes fails to connect to BOINC core.
6. Adds a minimum period between two scripts runs. This saves from unidentified behavior when script has been ran twice at a time by accidental double+ doubleclick :)
7. Detection of running BOINC. If BOINC is not running it will warn u with option to cancel operation.
8. At the end shows current GPU configuration - with other words what script has changed in this run(can be overridden by internal parameter).

About restart behaviors. They are 5 :) and are controlled with variable RestartBehaviour inside the script.
By number:
1 - the old behavior. Shows console window twice. See post 1 how it works and how its controlled.
2 - same but uses different method when starting BOINC. Show console window only once.
3 and 4 uses completely different method for shutdown the BOINC, by shutting down the Manager. Then problem with Manager not able to connect with client does not appear. But it needs manager window to be open and with focus, i.e to be topmost window when script is being ran.
Difference between 3 and 4 is than 3 uses old behavior, waiting certain amount of(specified in uDelay variable) time before starting BOINC, 4 uses automatic detection when BOINC process exists(it exits AFTER all client processes has exited too, so its save).
5 is most advanced - does not show any console junk, but sometimes BOINC manager fails to connect to client, as mentioned above. It happens rare and its not annoying. Running many clients apps MAY affect it, I had it when I was running two SETIs and 6+ Einsteins at same time. Solution is simple - quit Manager and start it again.
This one is preferred behavior.

New internal variables are:

var RestartBehaviour = 5;
var dueTimeout = 15000; // 15 seconds by default, time to wait BOINC to exit(or start after exit) when behaviour 5 is specified
var gracePeriodBetweenRuns = 5; // time between two runs of the script
var bRestartClient = true; //whether to restart BOINC or not after modifying XML config
var bSkipBackup = false;
var bNotifyUponCompletion = false;
var approxScriptRunTime = 5;

RestartBehaviour was explained.
dueTimeout is time to wait when stopping BOINC before canceling operation. I've added it, bcs once or twice BOINC was not responding for a long time and I had to kill the script. having this variable saves u from killing script manually. Its in milliseconds. Only works for behaviors 4 and 5.
gracePeriodBetweenRuns - minumum time elapsed between two script runs. Explained above why. Its in seconds. Script creates file named GPUSwitchLastRun.txt in same directory when it resides, where it writes its last run time. Just let u know what this file is, although its name is obvious. Default is 5 seconds.
var bRestartClient - if set to false(default is true) only config file will be altered accordingly, but the BOINC won't be restarted. Overridden by /n parameter. Using this parameter will be as setting this variable to true and client won't be restarted.
bSkipBackup - if false, it won't be made backup of cc_config file. It is controlled by /x parameter - adding it will skip backup, no matter what does variable value is. When no parameter is used, value of this variable is taken.
bNotifyUponCompletion - controls information message at the script exits.
Controlled by /m parameter. If parameter is omitted, then value in variable takes place.
approxScriptRunTime - in seconds, its expected time it takes for script to complete(observe it yourself and adjust it if needed). Its used for updating last run time of script. With the value specified here and gracePeriodBetweenRuns value, next ALLOWED time to run the script is adjusted.
Why? If script takes long to complete(e.g many clients to exit, etc) and next run time is adjusted only with gracePeriodBetweenRuns value, they you will be able to run script before its actually exited, if gracePeriodBetweenRuns is too short. Giving a hint to script how long it takes to complete will save some confused behavior. I had left it at 5 seconds for approxScriptRunTime, which is enough, imho, but if system is heavily loaded, it may need more time for BOINC to exit, increasing time of script run this way.
You may completely ignore this variable, but adjust gracePeriodBetweenRuns with value, which summarizes time for script run and period between runs.

All other rules from first thread message apply - how to install it, where etc, except you don't need to add GUI RPC password and u don;t need to create config file manually.

Use same link.
(I'll add new readme to the archive with better and wel lstructured explanation of script usage)

---

Very "BOINC-like" idea behind this script - to use idle resources always when they idle.
This script is definitely the form of optimizing application so it would be nice if link to this thread and script download location will be placed in Optimizing Apps sticky thread (to keep it in active for SETI@home community).

I've extended it further with ability to use nvidiaInspector( for dynamic clocks change.God bless this guy, finally we have way to tune ALL the clocks and fan with single doubleclick and without having target application running. And it is fast. I wish I can put my hands over NDA NVAPI!) Why? I use one clocks for gaming, and another for crunching, and latter are unstable for gaming, but perfectly OK for CUDA.
New version has integrated program scheduler, which runs external applications(in this case nvidiaInspector) to help achieve maximum with less attention to details.
In my case, I need to declock first GPU and not let SETI run on it, so I can play Civilization V, and when I don't play, I need to overclock it back and turn SETI run on it. Now its achievable with single doubleclick(even just one click, if u have shorcuts in taskbar's toolbar :) ) - set clocks and fan, modify XML, restart BOINC.
I'll give details and script itself later, I'm not @Home atm.
Also, it reminds me, the core part of script needs to be more clever, it does not handle situations where BOINC core runs as service. If someone needs such functionality, let me know, I'll add it.

---

This is an interesting idea. If I had more than 1 GPU to process with I would probably use it a lot. As there are often times I have to suspend GPU processing for stuff. An OS task could be created to run with reenabling all GPUs when the system has been idel for a long enough period.

Wouldn't it be more efficient to use "boinccmd.exe --read_cc_config" instead of restarting BOINC?

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

This is an interesting idea. If I had more than 1 GPU to process with I would probably use it a lot. As there are often times I have to suspend GPU processing for stuff. An OS task could be created to run with reenabling all GPUs when the system has been idel for a long enough period.

Wouldn't it be more efficient to use "boinccmd.exe --read_cc_config" instead of restarting BOINC?

GPU's are detected on start only, you can't enable/disable them just with a read config file.

Claggy