CPU <-> GPU rebranding

[Raistmer]

But since seti beta is basicly the same i could make this work, but is it wurth the trouble? (its totally designed for a single project now)

Not sure that there are many who needs rebranding for beta project (though I needed that for some time, but not too often). The real problem is: peoples who participate in both projects will be unable to use your program on SETI main too, where it is very needed.

[Marius]

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

[Marius]

Not sure that there are many who needs rebranding for beta project (though I needed that for some time, but not too often). The real problem is: peoples who participate in both projects will be unable to use your program on SETI main too, where it is very needed.

I agree a lot, beta not working isn't the worst thing what can happen, but it should certainly not conflict with main. I'm studying on this as we speak (together with a couple of other items which came up today).

Do you have a project url of seti beta? (or other url for additional info)

Greetings,
Marius

[Raistmer]

Sure.
<master_url>http://setiweb.ssl.berkeley.edu/beta/</master_url>

\projects\setiweb.ssl.berkeley.edu_beta\

[Josef W. Segur]

But since seti beta is basicly the same i could make this work, but is it wurth the trouble? (its totally designed for a single project now)

Not sure that there are many who needs rebranding for beta project (though I needed that for some time, but not too often). The real problem is: peoples who participate in both projects will be unable to use your program on SETI main too, where it is very needed.

Of the 3637 hosts active at Beta, 2741 are also active on SETI main (derived from http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php ).

Obviously the rebranding should either handle both cleanly, or be recoded to not affect Beta. The problem is that client_state.xml is only similar to real XML and the parts which apply to different projects are only separated positionally rather than being isolated properly by tags.
                                                                           Joe

[Samuel]

Thanks for clearing this up, this could/will save lots of rebranding compared to the current version. And thank you samuel7 for reminding me about it! (so logical when you hear it afterwards  )

You're welcome!

My cuda queue is 80% VHAR, so won't run your program now. Waiting for v1.9 with VLARonly...  

[Marius]

Obviously the rebranding should either handle both cleanly, or be recoded to not affect Beta. The problem is that client_state.xml is only similar to real XML and the parts which apply to different projects are only separated positionally rather than being isolated properly by tags.

LOL, the current xml is indeed kind of a clumbsy approach and i believe they are very well aware of it and are going to change it (over time). Sofar not much harm, it just needs some work on my side

[SETI-GPU-process]

Am I the only one having trouble downloading this?  

Can't get 1.7 or 1.8..says IE can't d/l from site...

Any other link to it available?

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.

[Purple Rabbit]

There's no actual need to rebrand VHAR. They run adequately on the GPU, and they don't cause any screen stuttering or other computer-use problems.

Ah ha (light bulb goes on)! I think this answers my question from a few days ago. VHAR doesn't error out with VLARKill 11, it just runs slightly (unnoticeably to a human?) slower. This could explain why moving VLAR/VHAR to the CPU, then moving 75% (with unknown, or unremembered settings) to the CPU only caused a little carnage with many more (ultimately successful) GPU tasks.

I apologize if someone patiently explained this to me previously. I just now understand. I sometimes need certain words in a special order 

Rick

[Brodo]

Also posted on the SAH Number Crunching Forum

BEWARE - UNEXPECTED SIDE EFFECT OF USING RESCHEDULE PROGRAM

Hi All
Reschedule works at the client level but if you use it to move 6.03 (CPU) units to the GPU when they are returned the server still thinks they were crunched by the CPU. As a result the server thinks you have one hellishly hot CPU and allocates extra units to the CPU accordingly.

Therefore if you have a slow CPU driving a fast video card you are likely to find that the CPU is allocated an impossible number of units for it to complete on time. e.g. I have a 3GHz P4 driving a GTS-250. When the dam broke and I was able to download units again I was allocated 349 units to the CPU and 200 to the GPU. These 349 units represent about a months crunching for the poor old P4. When I used ReSchedule to move some of these units to the GPU, as soon as I restarted BOINC it immediately set about downloading more CPU units to make up for the ones I had shifted.

So, if your using ReSchedule to move CPU units to the GPU be aware of this and keep an eye on the number of units that the server allocares and uploads to the CPU. At the moment I'm having to run "No New Tasks" to avoid CPU overload.

@ 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

[Purple Rabbit]

@ 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 minimize 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.

I'll second that 

I'm looking for tasks that don't abort, run reasonably well and maximize GPU usage. I use my GPU as an additional processor. Because it's kind of old (8600GTS, bought in May 2008...sigh) it can do the "normal" tasks in 30 to 45 minutes. The Q6600 does "normal" CPU tasks in about  1 hour  so they're almost the same in the grand scheme of things.  A minute or two one way or the other is insignificant for me.

Of course it's interesting playing with it 

Rick

[Marius]

@Brodo: Interesting, this would explain why my inputs are so unbalanced these day's. I was thinking this was caused by just swapping the contents of boinc data between different computers (a few week back everything dried up and i swapped a few computers). This not only gives a unbalance in applications but also in computers.

@Brodo/Rabbit: I'm working on the VLAR, and its already finished but i just want to play with it a little more before releasing it. Also want to test a bit more on Vista before i release this as that OS is causing less joy (=pain and problems) then i expected.

The server seems to give indeed a lot of vlar/vhar these day's, i do not know if thats because of rebranding or just bad luck.

Signing off,
Marius

[Purple Rabbit]

Great! I'm all ears 

I'm sure version 1.9 (or whatever) will be even better. It's been fun to play with your script just to see what it did. I'm not a programmer (just an old hardware engineer) so I'm allowed to consider these things to be magic. Besides it's ONLY software 

Rick

[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!

That's the best idea yet.  Just(ONLY) rebrand a VLAR if it is destined for a GPU.  Don't touch/modify anything else.  NADA.

Thanks!

Martin

waiting for version 1.9...

[kevin6912]

To bad the low angle range and high angle range to look for is not in INI file. Then people could increase the high angle range to something like 24.999 and the very high angle range tasks would be left on the GPU.

Regards,
Kevin