Forum > GPU crunching
CPU <-> GPU rebranding
Questor:
--- Quote from: Marius on 05 Jul 2009, 01:38:49 pm ---
--- Quote from: Questor on 04 Jul 2009, 07:07:01 pm ---Log says :
CPU tasks: 0 (0 VLAR/VHAR)
GPU tasks: 0 (0 VLAR/VHAR)
--- End quote ---
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
--- End quote ---
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:
--- Quote from: SETI-GPU-process on 05 Jul 2009, 03:05:10 pm ---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. :(
--- End quote ---
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:
--- Quote from: Mongo on 06 Jul 2009, 09:46:51 am ---
--- Quote from: Brodo on 05 Jul 2009, 04:14:50 pm ---
@ 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
--- End quote ---
I'll third this suggestion!
--- End quote ---
(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:
--- Quote from: Mongo on 07 Jul 2009, 07:27:40 pm ---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.
--- End quote ---
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:
--- Quote from: Josef W. Segur on 08 Jul 2009, 06:33:32 pm ---
--- Quote from: Mongo on 07 Jul 2009, 07:27:40 pm ---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.
--- End quote ---
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
--- End quote ---
I think you're saying the same thing I was (trying to say), Joe.
Hopefully, it will be clearer now to everyone.
Martin
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version