CPU <-> GPU rebranding

[Marius]

Ran Schedule 1.6 with a 50/50 split set in.  Seems it took the 4 work units already in progress on the CPU's and rebranded them to CUDA and when Boinc restarted new work units were started.  Leaving the newly created CUDA in paused mode.  Didn't expect that!  Would have been better to leave work already started alone.

Yes this is the current behaviour and it indeed leads to a lot of slots. And it will take some time before the stopped units will be restarted again. This is one of the reasons i rather use only the OnlyVLar option (unless CPU/GPU is serious unbalanced or berkeley is down).

And you can take this a step further and workout (with for example a 50% reschedule) a better workload distribution based on current deadlines. For example pushing cpu units to gpu just to lighten the workload stress on cpu side or the other way around. This is something to look at after a proper repear of windowss 64

Greetings,
Marius

[Geek@Play]

Ok, thanks Marius.

Will use the option to rebrand OnlyVLar from now on.

[Raistmer]

VLAR+VHAR rebranding could give better performance.

[glennaxl]

v1.7 and v1.5 doesnt work with x64

what is written from GPU to CPU:
windows_intelx86 to windows_intelx86
v1.3 works with x64

what is written from GPU to CPU:
windows_intelx86 to windows_x86_64
suggestion:
When it reads the client state file, platform should be placed into a variable.

CPU can be windows_intelx86 and windows_x86_64
GPU for now is only windows_intelx86

[Marius]

VLAR+VHAR rebranding could give better performance.

Yes it really does in the case of just vlar/vhar rebranding (but i guess people just hate to go to the trouble of installing the additional perl binaries)

Seems it took the 4 work units already in progress on the CPU's and rebranded them to CUDA and when Boinc restarted new work units were started.  Leaving the newly created CUDA in paused mode.

I can detect those and can leave them alone if possible. It just needs additional parsing.

v1.7 and v1.5 doesnt work with x64
v1.3 works with x64

AFAIK none of them ever worked on x64 unless the boincmgr (and boinc.exe in the background) is stopped. This is because all versions (should) lock the stdoutdae.txt to make sure boinc isn't running and that changes in client_state.xml wont be corrupted.

I guess what you are suggesting is that i should also change the platform in the results sections while rescheduling because there can be a difference in cpu or gpu application? If thats the ccase thats not a problem. Could you send your client_state.xml so i can see how it looks like (please use winrar or winzip, or use pvt msg).

Greetings,
Marius

[Raistmer]

VLAR+VHAR rebranding could give better performance.

Yes it really does in the case of just vlar/vhar rebranding (but i guess people just hate to go to the trouble of installing the additional perl binaries)

I meant VLAR+VHAR rebranding with your binary will give better performance than just VLAR rebranding.

[Marius]

I meant VLAR+VHAR rebranding with your binary will give better performance than just VLAR rebranding.

Oh darn, totally missed the point. Yes you are totally right, and this is what i meant in the first place, the option is called OnlyVLarVHar (and not OnlyVLar like i mentioned to Geek@Play).

[Geek@Play]

Marius......Is there a limit to the size of the log file or should it be removed manually, say once a month.

[Marius]

Marius......Is there a limit to the size of the log file or should it be removed manually, say once a month.

It has no limit (except for the partition or OS limitations) so it wont hurt to delete the file once in a while. Of cource it wont get that that big even while running once per hour

[Marius]

I installed windows 7 x64 and boinc (and spend day's waiting on a 1 freaking workunit) and confirmed the "Error:Error stopping BOINC service". Because there is no decent way to stop boinc in win/64 i need to terminate the boincmgr.exe and run "boinccmd --quit" to stop boinc.exe.

I do not really like this but its the only solution to run the scheduler on win/64 without having to stop boinc manually. Does anybody see any problems in killing boincmgr and boinc or is this method asking for trouble?

Greetings,
Marius

[Richard Haselgrove]

Do you even need to close the Manager? I leave mine open while rebranding (if I'm interested), and just stop the daemon. Manager goes blank for a while, shows 'not connected to a client', then repopulates the tabs when boinc.exe is running again.

I think the correct restart command in this case would be

boinc --detach

to avoid getting a redundant command window (see http://boinc.berkeley.edu/wiki/Client_configuration#Command-line_options).

[Marius]

Do you even need to close the Manager? I leave mine open while rebranding (if I'm interested), and just stop the daemon. Manager goes blank for a while, shows 'not connected to a client', then repopulates the tabs when boinc.exe is running again.

I think the correct restart command in this case would be boinc --detach

I must admit i wasn't aware of that command and i had indeed trouble restarting the client, thats why i killed and restarted the manager (which in turn also starts the client).

The use of a "boinccmd --quit" and later on a "boinc -detach" does a much cleaner job then killing boincmgr and the same approach will work very niceley on win/64 (it even works for win/32 with service approach).

Thanks,
Marius

[Raistmer]

Be careful with this "detach" option. It has significal delay in execution that led to trashing modified client_state or even to worse situations.
Some pause required.
Maybe better way is to kill boinc.exe process (ungraceful exit, but fast and reliable one).
Need to note that science apps can continue to work after such kill ~30 seconds. Usually they exit much faster.

[Richard Haselgrove]

Surely you need the delay after the --quit ?

That's what you do before you edit client_state: how long it takes to start up again afterwards doesn't really matter?

[Raistmer]

I talk not about restart time, I stress that boinc --quit option doesn't stop boinc deamon immediately.
This topic was discussed already on BOINC boards. Some watchdog loop needed to see if BOINC really stopped.
For what reason BOINC devs implemented this options in such way and why they don't provide true shutdown option - covered in darkness... (as most BOINC-related questions BTW )

EDIT: as experimental fact I killed BOINC's client_state completely while experimenting with rebranding script w/o "pause" in bat-file stopping BOINc....