CPU <-> GPU rebranding

[M_M]

Raistmer, could you please check EPG suggestion and release a new version of the script?

Thanks in advance.

[Raistmer]

Try this one


[attachment deleted by admin]

[EPG]

Tested with Seti MB 603,608 AP503, Einstein@home wus; looks ok to me.
Thank you very much!

[Raistmer]

Tested with Seti MB 603,608 AP503, Einstein@home wus; looks ok to me.
Thank you very much!

Fine. I used your hint about app_name along with other changes.

[M_M]

Seems to be working OK now. Thanks a lot.

[Marius]

This is a great idea, i'm still filling my queue after getting a new computer (and boinc is still running low on gpu units as queue starts with cpu tasks  )

Anywhay, I created a little tool for rebranding the units, copy it to your data directory and run from there. No additional binaries are needed, there's no unit limit and you can choose the percentage it needs to rebrand.

Just in case things go wrong (and as Raistmer always tells us), this is beta, make sure you disable network acces, stop boinc and make a safety copy.

This tool is a lot slower then the perl script as it parses all the xml 



[attachment deleted by admin]

[Raistmer]

No additional binaries are needed, there's no unit limit and you can choose the percentage it needs to rebrand.

Did you preserve AR ranges in your tool? The primary aim of original script not just to move part of tasks from GPU to CPU and vice versa, but to put on GPU only those tasks that computed better on GPU and leave other (VLAR included) on CPU.

[Marius]

Did you preserve AR ranges in your tool? The primary aim of original script not just to move part of tasks from GPU to CPU and vice versa, but to put on GPU only those tasks that computed better on GPU and leave other (VLAR included) on CPU.

Yes VLAR (<0.13) and VHAR (>1.127) are forced on to the cpu no matter what the choosen percentage is. The rest of the units can be swapped. Its done almost exactly as in the perl script with some extra code to get the percentages right. If there are a lot of vlar/vhar units the percentages can be off though.

[Raistmer]

Excellent!

[KarVi]

Just tried out Marius's reschedule app.

Seems to be working perfectly on my system.

Now all I would wish for was to make it accept simple cmdline parameters, so that I could run it in a bat-file.

It could look something like this:

net stop boinc
reschedule.exe 100  (the number tells the tool how much % to convert to CUDA)
net start boinc


Then I could schedule this bat-file to run once or twice a day, and have rebranding done automatically. Would be very nice.

[Marius]

No problem KarVi, i added a commandline param. When started you only see the process in the taskmanager as its a GUI application.

For pushing 75% of the units to the GPU use:
ReSchedule.exe /Autorun 75

Enjoy,
Marius





[attachment deleted by admin]

[Jason G]

Cool, I've also set this up on one of my machines in scheduled tasks to run once every three hours, using a batch file that stops boinc service first, then restarts it. Seems to be working. Nice one 

[Marius]

every three hours

In my experience each time you stop boinc service you will loose a (big) part of the workunits in process (unless you only run GPU). I guess executing it once every 24 or 48 hours would be fine to deal with the vlar/vhar problems.

[KarVi]

Thanks Marius for the swift developement of a new version.

Will set this up to run once every 24 hours, and see how things develop.

Thanks again, this will make things easier going ahead.

[Richard Haselgrove]

In my experience each time you stop boinc service you will loose a (big) part of the workunits in process (unless you only run GPU). I guess executing it once every 24 or 48 hours would be fine to deal with the vlar/vhar problems.

Then you have something wrong with your setup. I've lost about three or four tasks, in total, over several machines and several years. Unfortunately, most of them were CPDN tasks!

One set of problems was related to a failing hard disk (accepted for replacement under RMA) - BOINC apps couldn't read back their checkpoint files on restart.

Another cause is the <platform> tag which I erroneously put in early versions of the CUDA app_info.xml - if you still have that, it should come out.

I run a script which checks first to see how many VLAR tasks (and optionally VHAR tasks) are in the CUDA queue, and how close they are to the head of that queue. If nothing nasty is likely to happen in the near future, it doesn't bother with the stop/restart cycle - so I can run it as often as I like (every 6 hours seems plenty). Maybe you could think about something like that?