GUPPI Rescheduler is a small, simple command-line application for Linux and Windows designed to partially address the issue with SETI@Home GUPPI VLAR workunits, namely, that they run much more slowly on NVidia GPUs than "traditional" Arecibo multi-beam (MB) work units do, taking far longer to complete while resulting in the same credit, whereas if assigned to CPU they actually complete slightly faster than non-GUPPI, non-VLAR work. Thus for both credit and efficiency purposes it's optimal to reassign each work type to the platform that handles it best. I'm hoping that having the application available will also help to mitigate people aborting or deleting GUPPI work.

What GUPPI Rescheduler does is to move these GUPPI work units that are assigned to the GPU to CPU assignment, and vice-versa for the non-GUPPI, non-VLAR units which are moved from CPU to GPU assignment. Astropulse (ap) work units are not moved either way. When GUPPI Rescheduler is launched, it:

* Scans client_state.xml and sched_request_setiathome.berkeley.edu.xml to determine the client's platform and applications names/versions
* Finds and counts all non-started, non-GUPPI, non-VLAR MB work units assigned to CPU and reassigns them to GPU
* Finds up to that number of non-started GUPPI VLAR MB work units assigned to GPU and reassigns them to CPU (the reason for the "up to" is so that the client's queue won't grow without limit on successive runs by the slower CPU queue filling up with excessive GUPPI work units)
* Writes the changes to client_state.xml and exits (this is the only file that it changes... nothing is written unless there are changes so it can be run as often as wished. I suggest every few hours, or as long as it takes the machine's GPU or CPU to clear its queue, as optimal.)

GUPPI Rescheduler v0.4 download link - includes Linux and Windows versions and a ReadMe. More importantly, it includes the C++ source code (compiles in g++ in the gcc suite on Linux and Dev-C++ on Windows. Only one tiny change documented in the source needs to be made on the Windows build... CR/LF of course!) I release it under the terms of the GNU General Public License. You may post it anywhere you like but please keep it in the original unmodified .7z. You may use the source code as you wish; I would be very happy to see improvements and bugfixes, but of course under the terms of the GPL please include the source code with any public releases.

(I wrote this because I couldn't find Fred's Rescheduler, a similar app. that seems to have disappeared from the web. I'll keep mine available as long as possible, and it would be nice to have it added to any repositories ie Lunatics' for future reference. It may not be perfect, but at least it's something to build on which may help future development.)

Caveats:

* GUPPI Rescheduler will almost certainly work for you on Linux, but may not work on Windows. This is because the Linux GPU platforms are much fewer and thus the app. has a much higher chance of finding the right one and reassigning work to it, whereas on Windows there are an excess of platforms and several of them may be assigned to active GPU work at any time for some unknown reason. Please follow the ReadMe and back up client_state.xml on first run just in case it doesn't work, so that work is not lost.

* GUPPI Rescheduler will warn/terminate if it is run from the wrong folder, but it will not notice as it should if the client_state.xml file is still open. Therefore you should wait ten seconds after quitting BOINC Manager before running it (make sure to quit running apps. too! This is also in the ReadMe.)

* You can post in here if it does/doesn't work for you, but I may not make any updates to it in future. It works for me on both Linux and Windows, and did almost right away, and 90% or more of my development time was trying to make it work for everyone else, so I'm a little tired of fiddling with it and need to move on to other projects. You have the source code and are welcome to work on it. It's actually quite easy... I kept this a very simple program by not using headers, pointers or classes... just file I/O, variables/strings and string functions.

Stubbles69 has written a front-end .CMD batch file for Windows which works with GUPPI Rescheduler. This automates terminating BOINC Manager and also backing up client_state.xml. I haven't tested it so please contact Stubbles directly for any feedback. :^)

“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”---Margaret Mead

Great work!!!
Looking forward to see who finds it helpful :-D
Also, if anyone tries to integrate both scripts with Automated Tasks, please let others know how you did it...and how often/day it runs for your system.
Cheers,
RobG ;-}

Reading configuration files...
Warning: This machine appears to be attached to SETI@Home Beta.
If there are active Beta work units, this program may reassign them improperly,
as they look like SETI@Home work. OK to proceed (Y to continue)?Y
Found sched_request GPU platform=x86_64-pc-linux-gnu app_version=0 version_num=801
CPU platform=x86_64-pc-linux-gnu app_version=1 version_num=801 and GPU plan_class=cuda60
Searching for and moving work units in client state...
No non-GUPPI work units are assigned to CPU to move to GPU; no changes made.

I'm running anonymous with most blc4 wu being processed with GPU.

Follow is an extract from my client_state.xml (no change after running GUPPIRescheduler) about a vlar processed by GPU

I see a BLC GUPPI assigned to GPU in there which could be moved, but keep in mind that the determinant is the number of non-VLAR MB assigned to CPU. IF there are none, it won't do anything. Check for work units starting with a two digit and two letter month abbreviation without VLAR at the end and no plan_class ie cuda60 showing in parenthesis after the Application. If there are none, the program is working.“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”---Margaret Mead

This can happen if there aren't enough of a certain work unit type in your queue for it to make a determination. Give it a few hours until the queue is different and it should clear up, if not please advise.“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”---Margaret Mead

Just some quick feedback. App working well. First time I ran it on my 3 crunchers, it moved about 60-70 workunits to and fro on each machine. I just ran it again on each machine when I shut them down for peak power usage interval and it moved about 15 workunits. Seems to move a 1:1 swap of VLAR-non- guppi workunits. Already noticed a nice bump in RAC on each machine. Now just need to create a batch file for the app to make it easier to run instead of using the command prompt interface. Good job Mr. Kevvy!Seti@Home classic workunits:20,676 CPU time:74,226 hours

Just some quick feedback. App working well. First time I ran it on my 3 crunchers, it moved about 60-70 workunits to and fro on each machine. I just ran it again on each machine when I shut them down for peak power usage interval and it moved about 15 workunits. Seems to move a 1:1 swap of VLAR-non- guppi workunits. Already noticed a nice bump in RAC on each machine. Now just need to create a batch file for the app to make it easier to run instead of using the command prompt interface. Good job Mr. Kevvy!

Thank you. :^) It's much appreciated especially from someone all-Windows as I'm more concerned about it working on that platform (already pretty sure of Linux.) I did link to Stubbles' CMD in the first post at the bottom. Stubbles also indicated another one in development so hoping will reply here.

One thing I should put in the To Do list is to allow a command line parameter to prevent the "Y" requirement for if it detects SETI Beta.“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has.”---Margaret Mead

Just some quick feedback. App working well. First time I ran it on my 3 crunchers, it moved about 60-70 workunits to and fro on each machine. I just ran it again on each machine when I shut them down for peak power usage interval and it moved about 15 workunits. Seems to move a 1:1 swap of VLAR-non- guppi workunits. Already noticed a nice bump in RAC on each machine. Now just need to create a batch file for the app to make it easier to run instead of using the command prompt interface. Good job Mr. Kevvy!

Hey Keith,
That's great!
I'd appreciate it if you could try out my front-end script (*.cmd) to automate Mr. Kevvy's script (.exe). The link is the last one in Mr Kevvy's original post at the top...and here it is again: front-end .CMD batch file for Windows
Cheers,
Rob :-)

One thing I should put in the To Do list is to allow a command line parameter to prevent the "Y" requirement for if it detects SETI Beta.

I totally agree! ...as I'm done testing your script with S@h Beta and that's my only recommendation.
I'll only have to retest your script with S@h Beta if ever the apps from both project have the same version #s.

I missed that, sorry! I'll be sure to try out your script. It really doesn't take too much time to keyboard it as I'm an old command line interface guy, going back to OS/2 Warp and accustomed to it. Don't have to worry about Beta as I'm not trying that project on the main crunchers, just the Android phones and tablets.Seti@Home classic workunits:20,676 CPU time:74,226 hours

I missed that, sorry! I'll be sure to try out your script. It really doesn't take too much time to keyboard it as I'm an old command line interface guy, going back to OS/2 Warp and accustomed to it.

Great! ...so feel free to improve it in anyway you can think of.
The approach I took was to automate it bit-by-bit based on the manual procedure I had recently developed based on someone else's pointers.
In the comments (REM statements) I even put a few "TO DO" notes.
Also, the file compare (FC command) section could be improved.
I had to modify it quickly to work on a SETIzen's Core2Duo.
I looking forward to your comments and/or tweaks...or even a full revamp (if you feel it's needed).
Cheers,
Rob :-D

I let it shuffle my task queue and the work it assigned to my 980 Ti seems to be under-utilizing my GPU.
Tasks like 23mr10ad.19395.21846.4.31.181_1 and 21jl10aa.27240.23077.8.35.127_2 originally assigned to CPU seem to use only between 40-60% of the GPU when shifted over.
Do these tasks run better on the GPU provided you're multiprocessing?

Hey Shaggie,
I don't have any experience with any GPU other than GTX 750 Ti so my reply might not apply to your 980 Ti...but here goes:

Both of my main rigs are almost identical: HP Z400 (Xeon W3550 with HT enabled = 4+4 cores) and a GTX 750 Ti in each. I swap tasks on both with Mr Kevvy's script and my front-end .cmd file.

On my NV_SoG app rig, I run 1 GPU task at a time and they are all nonVLARs.
GPU-Z reports the GPU core being used at almost always at 100%.
In BoincTasks:
- those taking 14+mins report using 99.x% of assigned CPU core.
- the nonVLARs shorties: <1mins use about 75-90% of core
- those taking about 8mins use only 1-15% of a core.
- as for the others with a duration between 1 and 14 it's all over the place.
My guess is that the last group have various AR values that Raistmer wants reports on with his latest test releases.

As for my "Gold Standard" rig , I run the Cuda50 app with 3 tasks on GPU.
GPU-Z reports the GPU core being used at 80-95%range with an avg at ~90%.
Task manager reports 3-4% of CPU for each of the 3 GPU tasks as per my app_config.xml:

<gpu_usage>0.33</gpu_usage>
<cpu_usage>0.34</cpu_usage>

Other than the shorties using 43% of a core on avg with a range of 25-60%,
the others all take between 25-50 mins for 3 at a time with an avg of ~39mins (~13mins per task throughput) and BoincTasks reports the core being used at 18% to mid20s range mostly.

As for the other diff between the 2 rigs, I can only run up to 6 guppi tasks on CPU cores for NV_SoG rig; and
7 guppis on CPU for uda50 rig (..but currently only 6 in order to compare throughput since BoincTasks reports a diff of upto 10 mins diff between elapsed time and CPU run time when running 7)

I just tried Stubbles69 command script to automate Mr. Kevvy's app for rescheduling and it went well on all 3 machines. Except..... for some weirdness on shutdown on my daily driver. After I ran the script and closed the command window I proceeded to shutdown for the peak power interval electric rates as I normally do. The very first thing that happened that was strange and not noticed on the other machines was I got a brief glimpse of an error window saying that there was a problem in starting a workunit, in this case an AP work unit that had been running in the client before I shut it down and ran the script. I think it might have something to do with what this thread is tracking. 1073741205 Error Code (Unknown Error)

The thing I can't explain is why would I have seen this brief error about not finding the .DLL necessary to run the AP task when the BOINC Client and Manager had been cleanly exited ten minutes earlier and was not running at the time. I haven't had the chance to read through the thread mentioned yet to see what it is describing in detail. I just thought I had seen something similar previously in the threads that rang a bell.

The other thing that is unexplained is how I would have invoked the restarting of the client and manager when they are NOT started automatically. I manually start and shutdown BOINC each day on all machines.

Can the script somehow restart the client and manager?? I just did a very quick read through of the script before I used it to get an idea of what it was doing and I didn't see anything of the sort in my quick perusal. I did see that it does invoke BOINCTasks if it finds it on the machine and in this case the daily driver is my BOINCTask control machine and it might have been running at shutdown.

I will look for this issue tomorrow when I shut down for the day again to see if it reappears or was just some weird fluke.Seti@Home classic workunits:20,676 CPU time:74,226 hours

Hello Keith,
Thanks for the feedback.
My script (.cmd file) does restart the Boinc Client at the end with the line:

"C:\Program Files\BOINC\boinc.exe" --detach

but it isn't configured to restart the Boinc Manager...as I was intending to have it run as a scheduled task on a dedicated SETIrig so I didn't want to load anything in mem that wasn't needed as it could be used on older PCs.
At the beginning of the script, I was thinking of capturing which Managers (oinc Manager or BoincTasks) were open so that I could restart them at the end.
Feel free to modify it.

As for the AP issue, I have no clue.
I stopped testing Mr Kevvy's script while connected to S@h Beta when I got swamped with mostly APs for a few days (a dream on main...but a nightmare on Beta when you keep thinking that it has to end soon!!! lol). Maybe I should have continued a bit more with AP tasks, but my focus was on finding MB tasks on Beta that could get swapped incorrectly somehow.

As I said, I didn't really have the time to examine the script in detail, so I missed the restart of the client. I modified the script to not restart the client in my case since I intend to cleanly exit BOINC every day and not start up again for several hours.

I have noticed on my latest build that I still am running some Guppi vlars on the GPU's. I think I understand why especially with your comment about the AP's on BETA. I picked up a few AP CPU tasks on that machine today in the brief AP run and since I haven't finished 11 tasks so far, the task completion times are way out in never-never land and that has limited me in getting a normal full load of MB CPU tasks, so can't swap 1:1 the Guppi vlars onto the CPU's.

That will be the situation for a while on that machine I suppose since the rarity of AP being split and delivered so I expect it will take some calendar time to develop a realistic APR for CPU AP tasks and for the script and the app to fully engage. No issues on the older machines since they have stabilized APR's a long time ago.

Just a FYI datum for you. On my long-term crunchers, the MB CPU APR's have moved up from 26.~~ to 36.~~ or so just in the two days I have run the app. So, quite happy so far with the results.Seti@Home classic workunits:20,676 CPU time:74,226 hours

2) You do not need to taskkill boinctray.exe
It does not use client_state.xml
It is needed to detect user idle/busy time (keyboard mouse usage)
Without it running BOINC may not detect keyboard/mouse usage and continue running apps despite user selects "Suspend when computer is in use"

WRT your 1st point, I wanted to keep my initial release as simple as possible in order for others with limited batch file knowledge to be able to fairly easily understand the logic and steps, so that's why I documented some "assumptions" in the ReadMe file.

2) You do not need to taskkill boinctray.exe
It does not use client_state.xml
It is needed to detect user idle/busy time (keyboard mouse usage)
Without it running BOINC may not detect keyboard/mouse usage and continue running apps despite user selects "Suspend when computer is in use"

Prior to Mr Kevvy's script, my .cmd file was using Sublime Text 3 to do a Find and Replace All.
A few times, the Boinc Client had restarted before I had finished making and saving the changes.
The only reason I stopped the boinctray.exe process is because I thought it might be restarting the Boinc Client sometimes before it had finished saving the changes.

Is there a central place in GIThub where SETIzens can post their code for others to centrally modify?

Cheers, Rob ;-)
The script works as is for my 2 dedicated rigs on which I mostly use BoincTasks.
Since I am currently involved in other possible initiatives, I am looking for others to take over future changes to that script.