Manual 'branding' for stock Seti apps ?

since the rescheduler is an 3rd party app. and it is the creation of the wonderful folks ar Lunatics, then you might head to their website., register, and ask the question there. they created it they will know best

Thanks, I'm sure they will know best ... I'm registered there but I suspect they will suggest that I just dl and run the optimized apps ... then their Resched will work better.

Just curious to know if anyone here might know the 'simple' steps to do it manually for people like me who still use the stock apps.

You might be *very* right about that! We shall see ...

It's beginning to look like Re-scheduling tasks between the CPU and GPU is only going to work with the 'anonymous platform' mechanism.

Like you said, it doesn't look like I can get there from here with the stock apps.

Thanks. Looks like I'll just have to let my cache run out ... and then checkout the optimized goodies to put an app_info file in place.

You need to change three things in order to make the rebranding work:

* Change version number in <workunit>
* Change version number in <result>
* Remove <plan_class> from <result>

The tricky bit is matching up the <workunit> and the <result>. You need to do them in matching pairs.

Marius, who wrote the rebranding tool, hasn't posted since September 2009, when he wrote "... I'm swamped in work the last months. There's very little time left for seti at this moment.": so if you want to rebrand stock 609 applications, you'll probably have to adapt one of the scripts yourself.

I noticed that with the anonymous platform the tasks don't seem to be assigned to a specific <plan_class> ...

I don't remember this being discussed but it probably has:

Couldn't SETI just not issue VLAR/VHAR WUs to CUDA & keep them for CPU? I don't know enough about the details of how the back end works but rather ramble on for a couple of pages I'll leave it at that.

Heaven forbid that anyone think I am suggesting anything time consuming for the already over-busy guys at Berkley to do! It would get over one of the reasons to re-brand but not the BOINC confusion with 2 different apps running the same WUs on the same machine leading to a dearth of GPU WUs.

The main problem with CUDA at the moment seems to be the user experience of
screen 'stutter' and lagging while the GPU is processing VLAR tasks. The
extended runtime is unfortunate, of course, but I doubt many users would
notice it on its own: it's the display problem which draws users to the
message boards to express a feeling of dis-satisfaction with CUDA.

It seems as if the final resolution of the whole VLAR issue is taking longer
than anticipated. We had a brainstorming session at Lunatics this morning,
including most members of this distribution list: if there had been any
further news from Jorden's NB (copied into this email by bcc), I think it
would have been mentioned.

So, I make the following proposal to alleviate volunteer dis-satisfaction in
the short term, and buy additional breathing space for the long term
development.

Stop sending VLAR tasks to CUDA clients.

That sounds drastic, but I believe it would be surprisingly easy to do. The
key fact is this:

All true VLAR tasks have
<rsc_fpops_est>80360000000000.000000</rsc_fpops_est>

The scheduler has access to <rsc_fpops_est> (used to estimate task duration)
and could use it as a filter - something like:

CASE <rsc_fpops_est> == 80360000000000.000000
SET app_max_version = 603

- in other words, ensure that VLAR gets sent to a traditional (CPU)
application.

Advantages:
1) Greatly increased user satisfaction with CUDA
2) Slight reduction in result error rate (fewer aborts/autokills)
3) Slightly reduced bandwith usage (fewer resends)
4) Raistmer can stop playing with autokill mods, and go back to
optimising (!)

Disadvantages:
1) Code complexity, fiddling with scheduler - inevitable potential for
mistakes
2) Lower scheduler efficiency, possible impact on feeder queue.
3) <add your own here>

I am least able to quantify disadvantage (2), but I don't imagine it would
be too great. There should still be plenty of demand from stock 603
applications to soak up the likely number of VLARs, so the feeders shouldn't
clog up: and - as I was explaining to Matt in technical news last night -
the Arecibo 'weather forecast' for the next month suggests that task and
bandwidth demand will be lower than recently, because the 'basketweave'
survey has been replaced by a 'drift' survery thru March 12 (last date in
current public observing schedule).

One obvious point - the proposed scheduler change should be applied to the
Main project only: Beta stills needs the full range of ARs sent to CUDA apps
for testing.

Richard Haselgrove

Strangely enough this Changeset appeared today: Changeset 20419

- scheduler: add example code for SETI@home's situation


where app has both GPU and CPU versions,
but for certain jobs (VLAR WUs in this case)
the GPU version performs poorly and shouldn't be used.


The fix is a kludge - it will result in these jobs
not being sent to the host at all,
rather than being sent with the CPU app.
The current architecture makes it difficult to do otherwise.
One possible fix would be to create a separate app
for VLAR jobs, with only CPU app versions.

Claggy

How can I change a WU from 609 (cuda23) to 603?

I have looked at the ReScheduler from Lunatics but I am not sure that it will work with the stock Seti apps.

I tried stopping Boinc and then making the changes to the <workunit> ... <app_version>nnn field but, the WU's went back to the GPU when I rebooted and restarted Boinc.

Could anyone point me to more info about what is required to re-brand a WU when using the stock apps?