CPU <-> GPU rebranding

[Questor]

Log says :
CPU tasks: 0 (0 VLAR/VHAR)
GPU tasks: 0 (0 VLAR/VHAR)

I investigated the client_state.xml you send me and the xml is corrupt causing my xml parser (and also IE8 parser) to truncate large parts of the xml.

IE8 report the following error: End tag 'iax_nbytes' does not match the start tag 'max_nbytes'.
  <max_nbytes>65536</iax_nbytes>

Simply fixing that will solve this problem.

Greetings,
Marius

Thanks Marius - an excelllent bit of detective work! and apologies I didn't spot it but as BOINC seemed to be working OK I foolishly assumed everything was fine. As per PM I have fixed that error and Reschedule now sees all my WUs.

However I now get :-

Error :  List index out of bounds (0)
 
If I tick the two boxes 'Only VLAR/VHAR to CPU' and 'use True angle rate' it tests OKs. Not sure of your underlying logic as to what might be causing this.

As mentioned I now have suspicions over the health of this machine so if this doesn't ring immediate bells then I'm going to do further checks on the BOINC data files and diagnostics on the machine.

[BANZAI56]

I downloaded ReSchedule 1.8 about 6 hours ago and just did so again 3 minutes ago, just to make sure. Using Firefox 3.5 under Vista x64.

Unfortunately, currently I have no SETI work units to try out ReSchedule.

Thanks, it was just me or more specifically the browser on the rig I was using.

Got it using a different rig and probably a less choked off browser.   

[Mongo]

@ Marius.
Would it be possible to add an option to this program to only move VLAR's to the CPU and leave the VHAR's on the video card(s) ? It would help minimise this problem and the issues where a large number of units get moved to the CPU. As Richard said there is really no need for the VHAR's to be moved.

Thanks
Brodo

I'll third this suggestion!

(It's amazing how a couple hours sleep can help the thought processes...)

In order to diminish or eliminate the effect of rebranding, which Brodo has brought to everyone's attention, the ratio of GPU-to-CPU MB's should not be altered,
even if all you want to do is keep VLAR/VHAR's from going to a GPU.

So, however many VLAR/VHAR's are rebranded from GPU-toCPU, the same number of CPU bound MB's should be rebranded for the GPU.

This will preserve the ratio the client has received from SETI's servers and will not confuse their bookkeeping.

Thanks to Raistmer (perl scripts) and Marius (ReSchedule) for your efforts to improve the SETI experience!!!

Martin

waiting/hoping for 1.9

[Josef W. Segur]

In order to diminish or eliminate the effect of rebranding, which Brodo has brought to everyone's attention, the ratio of GPU-to-CPU MB's should not be altered,
even if all you want to do is keep VLAR/VHAR's from going to a GPU.

So, however many VLAR/VHAR's are rebranded from GPU-toCPU, the same number of CPU bound MB's should be rebranded for the GPU.

This will preserve the ratio the client has received from SETI's servers and will not confuse their bookkeeping.

Actually, it's not the number of WUs, rather the time estimates which need to be kept in balance to avoid confusing BOINC.

Rebranded to CPU increases BOINC's estimate of how much crunch time the cache represents, to GPU decreases time (assuming the GPU is faster).

While rebranding, one might add up the rsc_fpops_est values for tasks shifted to the CPU then shift tasks to GPU and subtract their values, stop when the total is near zero. That would avoid any drastic work fetch action by the core client when it's restarted. Even that could still leave some oddball situations if there's only one GPU but several CPUs, for instance BOINC's round robin simulation might decide some of the work needs high priority and work fetch would be disabled for awhile.

Options which attempt to achieve a selected balance between CPU and GPU probably can't keep that time balance, but it might be used as a streering factor in deciding which tasks to shift.
                                                                                  Joe

[Mongo]

In order to diminish or eliminate the effect of rebranding, which Brodo has brought to everyone's attention, the ratio of GPU-to-CPU MB's should not be altered,
even if all you want to do is keep VLAR/VHAR's from going to a GPU.

So, however many VLAR/VHAR's are rebranded from GPU-toCPU, the same number of CPU bound MB's should be rebranded for the GPU.

This will preserve the ratio the client has received from SETI's servers and will not confuse their bookkeeping.

Actually, it's not the number of WUs, rather the time estimates which need to be kept in balance to avoid confusing BOINC.

Rebranded to CPU increases BOINC's estimate of how much crunch time the cache represents, to GPU decreases time (assuming the GPU is faster).

While rebranding, one might add up the rsc_fpops_est values for tasks shifted to the CPU then shift tasks to GPU and subtract their values, stop when the total is near zero. That would avoid any drastic work fetch action by the core client when it's restarted. Even that could still leave some oddball situations if there's only one GPU but several CPUs, for instance BOINC's round robin simulation might decide some of the work needs high priority and work fetch would be disabled for awhile.

Options which attempt to achieve a selected balance between CPU and GPU probably can't keep that time balance, but it might be used as a streering factor in deciding which tasks to shift.
                                                                                  Joe

I think you're saying the same thing I was (trying to say), Joe.

Hopefully, it will be clearer now to everyone.

Martin

[Geek@Play]

Have no idea what Reschedule.elf is but Reschedule created it today.  Attached for your inspecion.



[attachment deleted by admin]

[Marius]

Have no idea what Reschedule.elf is but Reschedule created it today.  Attached for your inspecion.

Its just a text file containing information about the failure. Unfortunateley i could not extract the exact reason why it was unable to stop the boinc service. It could be because of the 5 seconds timeout i used, 5 sec could be a bit too tight and i extended this to 15 sec.

[Raistmer]

Better make this timeout value adjustable (with default of 15 sec or whatever you want). With high-performance hosts each idle second counts

[Marius]

Better make this timeout value adjustable (with default of 15 sec or whatever you want). With high-performance hosts each idle second counts

lol, if it cant stop boinc under 15 seconds the host doesn't deserve to be running boinc

[Raistmer]

Better make this timeout value adjustable (with default of 15 sec or whatever you want). With high-performance hosts each idle second counts

lol, if it cant stop boinc under 15 seconds the host doesn't deserve to be running boinc

I meant something exactly different:
If it will await 15 seconds when BOINC could be stopped for one second - 14 seconds are lost for processing

I'm using now your 1.8 rebranding tool (in manual mode for now) on my x64 host.
One time it complained about can't stop BOINC service (so some adjustments in this area really needed to be done) (but before it could stop it and start again).
But basic functionality works just fine + additional bonus of work balancing between CPU/GPU is just great (especially in times there was no new wrok from servers and CUDA queue completely dry).
Thank you for such nice looking and very useful tool!
IMHO it should be required tool on any CUDA enabled SETI host now.

[Marius]

I meant something exactly different:
If it will await 15 seconds when BOINC could be stopped for one second - 14 seconds are lost for processing

Speaking about junks talking about 10 whole seconds lost

I'm using now your 1.8 rebranding tool (in manual mode for now) on my x64 host.
One time it complained about can't stop BOINC service (so some adjustments in this area really needed to be done) (but before it could stop it and start again).
But basic functionality works just fine + additional bonus of work balancing between CPU/GPU is just great (especially in times there was no new wrok from servers and CUDA queue completely dry).
Thank you for such nice looking and very useful tool!
IMHO it should be required tool on any CUDA enabled SETI host now.

Hey thanks man, remember its basicly your tool as i just took your excellent idea and extended it a little bit (basicly i picked it up because my queue went dry back then)


This reminds me that i actually forgot to publish the 1.9

1.9 changes:
-Now display's the amount of VLAR and VHAR
-Changed the parsing of client_state.xml so seti@home beta can be run also
-Automatic detection of the right seti_enhanced applications so this tool
 can also work with future versions of the seti applications.
-VHAR is now only optionally rescheduled to the CPU (see settings)
-Alternative detection of VLAR/VHAR (True Angle Rate) has been removed.

-->Also noticed 2 little problems:
-Noticed tool does not automaticly pickup seti paths under vista (security problem)
-Noticed tool crashes when browsing for data path under vista (please enter the path manually)

Enjoy,
Marius

[attachment deleted by admin]

[Samuel]

This reminds me that i actually forgot to publish the 1.9

Thanks for the new version.

I haven't run it yet as I just ran Raistmer's script but on the settings tab the first option is still 'Only VLAR+VHAR to CPU.' I suppose this is just a cosmetic leftover and the functionality has changed.

Do I understand correctly that the tasks already being crunched are excluded from the figures? If so, the test function returned correct figures.

On my Vista64, the paths were picked up automatically and I was able to browse for the data path.

[Raistmer]

This reminds me that i actually forgot to publish the 1.9

on the settings tab the first option is still 'Only VLAR+VHAR to CPU.' I suppose this is just a cosmetic leftover and the functionality has changed.

I noticed that too and perceive it as "not touch usual tasks and not  do % rebranding"
Cause VLAR and VHAR now counted separately (good idea actually) it's very easy to check.

[Marius]

I haven't run it yet as I just ran Raistmer's script but on the settings tab the first option is still 'Only VLAR+VHAR to CPU.' I suppose this is just a cosmetic leftover and the functionality has changed.

Yes small leftover, the first checkbox locks out the percentage (it grays some controls also to reflect that) and the second checkbox controls if the vhar are pushed back to the cpu.

Do I understand correctly that the tasks already being crunched are excluded from the figures? If so, the test function returned correct figures.

Yes, the currently running units are always excluded because i can't switch the applications of those because that info has already been entered into the slot directory (previous versions did reschedule those, but i doubt if that had any effect).

On my Vista64, the paths were picked up automatically and I was able to browse for the data path.

Thats good to hear, here with a unpatched vista 64 under virtualbox it just refuses (even when it was run as adminisrator).

Thanks for reporting back,
Marius

[Geek@Play]

I feel I must echo Raistmer's comments..........

Thank you for such nice looking and very useful tool!
IMHO it should be required tool on any CUDA enabled SETI host now.

Thank You