+- +-
Say hello if visiting :) by Gecko
11 Jan 2023, 07:43:05 pm

Seti is down again by Mike
09 Aug 2017, 10:02:44 am

Some considerations regarding OpenCL MultiBeam app tuning from algorithm view by Raistmer
11 Dec 2016, 06:30:56 am

Loading APU to the limit: performance considerations by Mike
05 Nov 2016, 06:49:26 am

Better sleep on Windows - new round by Raistmer
26 Aug 2016, 02:02:31 pm

Author Topic: CPU <-> GPU rebranding  (Read 205033 times)

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: CPU <-> GPU rebranding perl script
« Reply #105 on: 26 Jun 2009, 02:08:05 pm »
...
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 ;) )
...

Not such a mystery if you think about the opposite case, whereby Boincapi kills science applications without prejudice.  :-X

Offline Raistmer

  • Working Code Wizard
  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 14349
Re: CPU <-> GPU rebranding perl script
« Reply #106 on: 26 Jun 2009, 02:20:04 pm »
...
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 ;) )
...

Not such a mystery if you think about the opposite case, whereby Boincapi kills science applications without prejudice.  :-X
Well, it kills science app ungracefully pretty often but doesn't allow to do this with itself... not very nice behavior ;)


EDIT: actually, the question doesn't in this area.
I have no objections to wait a little before BOINC will cloase all apps and itself. I have BIG OBJECTION for fact that boinc --quit returns IMMEDIATELY while BOINC still not stopped! This is a "root of evil"
« Last Edit: 26 Jun 2009, 02:22:53 pm by Raistmer »

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: CPU <-> GPU rebranding perl script
« Reply #107 on: 26 Jun 2009, 02:27:14 pm »
Well, it kills science app ungracefully pretty often but doesn't allow to do this with itself... not very nice behavior ;)

Exactly.  It's just like the science app has a wife:

" Do this"

"Don't Do that"

"You don't own me!"

"Give me your Credit Card, I'm Going Shopping"

Personally, I'm waiting on Richard's Boinc-Lite edition, which apparently comes with its own gag.

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: CPU <-> GPU rebranding perl script
« Reply #108 on: 26 Jun 2009, 02:38:01 pm »
...
EDIT: actually, the question doesn't in this area.
I have no objections to wait a little before BOINC will cloase all apps and itself. I have BIG OBJECTION for fact that boinc --quit returns IMMEDIATELY while BOINC still not stopped! This is a "root of evil" ...

Oh...  that's the programmatic equivalent of "Yes Dear."

Offline Raistmer

  • Working Code Wizard
  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 14349
Re: CPU <-> GPU rebranding perl script
« Reply #109 on: 26 Jun 2009, 02:39:05 pm »
;D ;D ;D

Offline Marius

  • Knight o' The Realm
  • **
  • Posts: 84
Re: CPU <-> GPU rebranding perl script
« Reply #110 on: 27 Jun 2009, 06:28:31 am »
Oh...  that's the programmatic equivalent of "Yes Dear."

ROTFL, oh dear ;)

Doesn't hurt to see if boinc.exe has really closed down i guess ;D



Offline Marius

  • Knight o' The Realm
  • **
  • Posts: 84
Re: CPU <-> GPU rebranding perl script
« Reply #111 on: 30 Jun 2009, 09:56:13 am »
A new version of the rescheduler which now also works on the win/64 platform. If you are running this platform *please* make a backup copy first just in case it is not working as expected. Also there are additional settings so please check the configuration (via the tabsheets) as it needs your boinc bin and data path.

Greetings,
Marius

-Running units are now excluded from the rescheduling (better because the
slot info wasn't changed). Because of the changed deadlines it is still
possible that boinc starts other tasks while the previous running tasks
are marked as waiting.
-The platform is now also changed while rescheduling (sorry about any
inconvenience if this has caused problems)
-Because of changed locking there are two new settings for binaries and
datapath. (There is no need to copy reschedule to the datapath anymore)
-If boinc is not installed as a service it will do a "boinccmd.exe --quit"
and after the reschedule a "boinc.exe -detach". This should solve the
problems on any system where boinc is not installed as a service (win/64).
-Changed the locking scheme (it is no longer locking the stderrdae.txt to
test if boinc is running).
-Solved some problems in the test algorithm for the automatic reschedule.



[attachment deleted by admin]

Offline Raistmer

  • Working Code Wizard
  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 14349
Re: CPU <-> GPU rebranding perl script
« Reply #112 on: 30 Jun 2009, 12:58:13 pm »
-If boinc is not installed as a service it will do a "boinccmd.exe --quit"
and after the reschedule a "boinc.exe -detach". This should solve the
problems on any system where boinc is not installed as a service (win/64).
Expect client_state.xml corruption here... (due to BOINC --quit option behavior).

Offline Marius

  • Knight o' The Realm
  • **
  • Posts: 84
Re: CPU <-> GPU rebranding perl script
« Reply #113 on: 30 Jun 2009, 01:16:05 pm »
-If boinc is not installed as a service it will do a "boinccmd.exe --quit"
and after the reschedule a "boinc.exe -detach". This should solve the
problems on any system where boinc is not installed as a service (win/64).
Expect client_state.xml corruption here... (due to BOINC --quit option behavior).
No, the command is "boinccmd.exe --quit" not "boinc.exe -quit" or are we talking about the same? Have you experienced this before and what are the circumstances that happened?

if you refer to boinc.exe not exiting immediately, i have that covered by checking if the process has exited. Has been running well for the last couple of days.

Greetings,
Marius

Offline Raistmer

  • Working Code Wizard
  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 14349
Re: CPU <-> GPU rebranding perl script
« Reply #114 on: 30 Jun 2009, 03:36:21 pm »
if you refer to boinc.exe not exiting immediately, i have that covered by checking if the process has exited. Has been running well for the last couple of days.
Fine, if you do additional check all should be OK then.
Yes, I meant that boinc doesn't exit immediately and boinccmd --quit returns before boinc.exe will finish.

Offline Purple Rabbit

  • Squire
  • *
  • Posts: 38
Re: CPU <-> GPU rebranding perl script
« Reply #115 on: 30 Jun 2009, 05:17:52 pm »
Please forgive me if I'm being dense. I'm an engineer, not  a programmer, but I can (usually) figure things out  ;) I have been using the various Marius versions (currently 1.8 ), but I have noticed an interesting (to me) thing.

I normally run Marius in the "find VLAR/VHAR" mode. In the last day that was almost all of them...sigh. Because a 100 of these puppies waiting for the CPU was a bit excessive, I went for the 75% to GPU option (as an experiment) without the VLAR/VHAR option (but after running VLAR/VHAR).

I got the requested mix, but Marius 1.8 didn't show the change (bug, or perhaps something no one would want?). BOINC showed the change after starting. I manually stop and start BONIC  because I don't trust the script (sorry).  Anyway, most of the changed VLAR/VHAR (back to the GPU) tasks (previously tagged as CPU) ran fine within normal (wall clock) times.

Three died in Varkill. I can't help but wonder why the others didn't. OK, I understand that Marius has different parameters. Perhaps they are too strict or am I missing something?

My computer is a Q6600 with 8600GTS video card running on Vista.

No big deal, but I kind of wonder why I can process tasks on the GPU that Marius says are poison :)
« Last Edit: 30 Jun 2009, 05:50:10 pm by Purple Rabbit »

Offline Raistmer

  • Working Code Wizard
  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 14349
Re: CPU <-> GPU rebranding perl script
« Reply #116 on: 30 Jun 2009, 05:53:23 pm »

Three died in Varkill. I can't help but wonder why the others didn't. OK, I understand that Marius has different parameters. Perhaps they are too strict or am I missing something?


No big deal, but I kind of wonder why I can process tasks on the GPU that Marius says are poison :)

Other didn't just because they were VHARs, not VLARs.
[
VHAR not so slow as VLAR, it just not as efficient on GPU as midrange AR tasks are. So no reason to "kill"them, but if there is a  possibility to send them on CPU - why not ;)
Consider this as further performance optimization
]
« Last Edit: 30 Jun 2009, 05:57:32 pm by Raistmer »

Offline Marius

  • Knight o' The Realm
  • **
  • Posts: 84
Re: CPU <-> GPU rebranding perl script
« Reply #117 on: 30 Jun 2009, 06:05:54 pm »
Please forgive me if I'm being dense. I'm an engineer, not  a programmer
;) I'm a programmer in real live, not a astronomer or engineer and seti is just one of my many bad habits..

I got the requested mix, but Marius 1.8 didn't show the change (bug, or perhaps something no one would want?).
If you show the interesting part of your log we can figure out exactly what happened. The tool always pushes V*AR to the CPU just like Raistmer scripts does (bit depending if you checked the True Angle Rate) and additionally it tries to make the proper distribution which is not always possible if you have many V*AR.

Three died in Varkill. I can't help but wonder why the others didn't. OK, I understand that Marius has different parameters. Perhaps they are too strict or am I missing something?

My computer is a Q6600 with 8600GTS video card running on Vista.

No big deal, but I kind of wonder why I can process tasks on the GPU that Marius says are poison :)
I have no idea why VLARKILL occurred even after a reschedule. I think Raistmer can answer this one better then me. However i noticed a couple of vlarrkils on my account also while using the tool, but nearly not as much as it used to be (before that complete series went down the drain).

Greetings,
Marius

Offline Purple Rabbit

  • Squire
  • *
  • Posts: 38
Re: CPU <-> GPU rebranding perl script
« Reply #118 on: 30 Jun 2009, 06:33:34 pm »
OK, I'm kind of getting the idea . VHAR tasks aren't necessarily bad, but send them to the CPU anyway.  Perhaps a bit wasteful (in my case).  I would prefer to do whatever the GPU can do (at least somewhat efficiently) on the GPU (or at least a choice).

I changed the parameters on the Reschedule after I looked for VLAR/VHAR stuff.  I ran it looking for VLHR/VHAR first. Then I ran 75% GPU. I got a bunch more GPU tasks. I'm using CPU tasks to keep the STD down. I'd really like to just run GPU stuff.

I don't discriminate between programmers and engineers. We're both good people even if you people are a bit strange  ;D What part of the log is interesting? I'm in the weekly Tuesday SETI  hold right now so I've got everything.

Like I said, it's no big deal. I'll make it work or I'll throw up my arms and declare that all the world is against me  ;D Actually not, I'm here for the duration !

Rick
« Last Edit: 30 Jun 2009, 07:54:17 pm by Purple Rabbit »

Offline Geek@Play

  • Alpha Tester
  • Knight Templar
  • ***
  • Posts: 330
Re: CPU <-> GPU rebranding perl script
« Reply #119 on: 01 Jul 2009, 02:19:09 am »
Thanks for the update Marius. ;D
Boinc....Boinc....Boinc....Boinc

 

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?
Members
Total Members: 97
Latest: ToeBee
New This Month: 0
New This Week: 0
New Today: 0
Stats
Total Posts: 59559
Total Topics: 1672
Most Online Today: 171
Most Online Ever: 983
(20 Jan 2020, 03:17:55 pm)
Users Online
Members: 0
Guests: 146
Total: 146
Powered by EzPortal