Donate To Seti@HomeSeti@Home optimized science apps and information
 
Welcome, Guest. Please login or register.
21 Dec 2014, 09:48:34 pm

Login with username, password and session length
 
» Home
» Forums
» Downloads
» FAQ
» News

» Search site
 
 
 
If you've registered already but never got your activation email, please click here.
 
 
Seti@Home optimized science apps and information  |  Optimized Seti@Home apps  |  Windows  |  GPU crunching  |  Topic: CPU <-> GPU rebranding 0 Members and 0 Guests are viewing this topic. « previous next »
Pages: 1 ... 11 12 [13] 14 15 ... 25 Go Down Print
Author Topic: CPU <-> GPU rebranding  (Read 95887 times)
Questor
Guest


Email
Re: CPU <-> GPU rebranding perl script
« Reply #180 on: 06 Jul 2009, 11:24:30 am »

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.
Logged
BANZAI56
Squire
*
Offline Offline

Posts: 20


Re: CPU <-> GPU rebranding perl script
« Reply #181 on: 07 Jul 2009, 01:13:53 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. Sad


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.   Undecided

Logged
Mongo
Guest


Email
Re: CPU <-> GPU rebranding perl script
« Reply #182 on: 07 Jul 2009, 07:27:40 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


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
Logged
Josef W. Segur
Janitor o' the Board
Knight who says 'Ni!'
*****
Offline Offline

Posts: 2981


Re: CPU <-> GPU rebranding perl script
« Reply #183 on: 08 Jul 2009, 06:33:32 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.

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
Logged
Mongo
Guest


Email
Re: CPU <-> GPU rebranding perl script
« Reply #184 on: 10 Jul 2009, 08:53:06 am »

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
Logged
Geek@Play
Alpha Tester
Knight Templar
***
Offline Offline

Posts: 330



Re: CPU <-> GPU rebranding perl script
« Reply #185 on: 11 Jul 2009, 02:14:01 pm »

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


* ReSchedule.zip (4.98 KB - downloaded 494 times.)
« Last Edit: 11 Jul 2009, 02:26:59 pm by Geek@Play » Logged

Boinc....Boinc....Boinc....Boinc
Marius
Knight o' The Realm
**
Offline Offline

Posts: 84


Re: CPU <-> GPU rebranding perl script
« Reply #186 on: 11 Jul 2009, 04:38:34 pm »

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.
Logged

Raistmer
Working Code Wizard
Volunteer Developer
Knight who says 'Ni!'
*****
Offline Offline

Posts: 12894



Re: CPU <-> GPU rebranding perl script
« Reply #187 on: 12 Jul 2009, 07:03:56 am »

Better make this timeout value adjustable (with default of 15 sec or whatever you want). With high-performance hosts each idle second counts Grin
Logged
Marius
Knight o' The Realm
**
Offline Offline

Posts: 84


Re: CPU <-> GPU rebranding perl script
« Reply #188 on: 12 Jul 2009, 07:39:00 am »

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

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

Raistmer
Working Code Wizard
Volunteer Developer
Knight who says 'Ni!'
*****
Offline Offline

Posts: 12894



Re: CPU <-> GPU rebranding perl script
« Reply #189 on: 12 Jul 2009, 09:48:02 am »

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

lol, if it cant stop boinc under 15 seconds the host doesn't deserve to be running boinc Wink
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 Wink

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.
Logged
Marius
Knight o' The Realm
**
Offline Offline

Posts: 84


Re: CPU <-> GPU rebranding perl script
« Reply #190 on: 12 Jul 2009, 10:20:30 am »

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 Wink
Speaking about junks talking about 10 whole seconds lost Shocked

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

* ReSchedule1.9.rar (446.85 KB - downloaded 955 times.)
Logged

Samuel
Guest


Email
Re: CPU <-> GPU rebranding perl script
« Reply #191 on: 12 Jul 2009, 11:00:23 am »

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.
Logged
Raistmer
Working Code Wizard
Volunteer Developer
Knight who says 'Ni!'
*****
Offline Offline

Posts: 12894



Re: CPU <-> GPU rebranding perl script
« Reply #192 on: 12 Jul 2009, 11:05:15 am »

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.
Logged
Marius
Knight o' The Realm
**
Offline Offline

Posts: 84


Re: CPU <-> GPU rebranding perl script
« Reply #193 on: 12 Jul 2009, 11:30:44 am »

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
Logged

Geek@Play
Alpha Tester
Knight Templar
***
Offline Offline

Posts: 330



Re: CPU <-> GPU rebranding perl script
« Reply #194 on: 12 Jul 2009, 11:53:05 am »

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
Logged

Boinc....Boinc....Boinc....Boinc
Pages: 1 ... 11 12 [13] 14 15 ... 25 Go Up Print 
Seti@Home optimized science apps and information  |  Optimized Seti@Home apps  |  Windows  |  GPU crunching  |  Topic: CPU <-> GPU rebranding « previous next »
Jump to:  


Quote!
Nature always sides with the hidden flaw.
- Murphy's Law

 
Site Statistics
Total Members:97
Total Posts:56,120
Total Topics:1,583
Downloads
..Some PHP stuff ToDo
Pages served
Today:3,342
Total:20,262,440
(since 6/26/2006)
Latest Member:
Gecko
 
 
Seti@Home optimized science apps and information | Powered by Enigma 2.0 (RC1).
© 2003-2014, LSP Dev Team. All Rights Reserved.
Seti@Home optimized science apps and information Forums | Powered by SMF.
© 2005, Simple Machines LLC. All Rights Reserved.
Powered by MySQL Powered by PHP Valid XHTML 1.0! Valid CSS!