Yes.

This is entirely unnecessary. All of the extra app versions are doing no harm. However it's a bit confusing and overwhelming.

I'm crunching three different types of workunits, MB V6, MB V7 and AP V6.

I'm crunching them with both CPU and GPU apps.

Each of these have two platforms (I'm on Windows 7 64-bit), windows_intelx86 and windows_x86_64.

Each GPU under each platform of each workunit type has three or four "plans", *ati_opencl_100, opencl_ati_100 and ati13ati for AP V6; *opencl_ati5_sah, opencl_ati5_cat132, opencl_ati_sah and opencl_ati_cat132 for MB V7; ati_opencl_sah, *opencl_ati_sah and ati13ati. The asterisk shows which plan each WU is using.

So my app_info has three tasks, two platforms for each, one CPU and three or four GPU plans for each. So 26 where in theory 6 will do.

Can I at least purge the 32-bit platform parts, I'm running 64-bit BOINC on a 64-bit OS? That at least cuts in in half.

Yes it's totally, totally unnecessary, stupid and full of potential pitfalls if I screw something up but it looks as if I'm going to need to add <flops> again as MB V7 valid non -9 overflow WU aren't being counted as completed so a server side flop estimate will not be made. Admittedly the current flop estimate that the server is using is noticeably better than what V6 was but it's still off by a factor of 1.6 and I have no idea yet of the factor will be the same for MB, give me a month. But going through 20 plans to add it is annoying and somewhat confusing since 95% of each chunk is identical.

Yes I know, cc_config.xml is suppose to be the place to do this but this way I can tune for each type of app.

So am I insane? Bad case of virtual OCD? Too much time on my hands(cue Styx)?

---

"Life is just nature's way of keeping meat fresh." - The Doctor

What I find easiest with mine, and yes I do like to 'clean up' after everything's running ok (at my own risk), is prune the individual aistubs of everything not in use, then run aimerge.cmd from the installer. FWIW i find that procedure easiest for app_info customisations as well, mostly since I do have a highlighter, but no suitable long corridor , wide daisywheel printer and tractor feed paper.

Whatever you trim to, do keep 'standard' plan_class labels though, as it'll make future update/migration a lot smoother.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

The extra <app_version>s are really only there to pick up work in progress - any and all possible work in progress, with either stock denominations or previous installer denominations.

Once you have no 'old' work left - i.e. only one plan_class ist showing up - you can remove all the extra and doubled-up ones.
You need to keep the top entry for every app. [plan_class matching task branding] - one v7 and one v6 each [the latter in case of resends].
You should be able to lose the extra platform_tag one as well, AFAIK only the top one per set will ever be used. You may want to have a look in client_state.xml what kind of platform_tag the tasks have been assigned - should all be the top one - and if you only have the 32bit tag (don't ask me why I didn't put 64bit in front) you're ok to remove the additional 64bit platform tag app_version as well.

Um. In short, at your own risk, everything but the first per set can go.
Makes 6 - 3 CPU (MB v6, MB v7 and AP v6), 3 GPU (same).

Reminds me, should trim my own, to have it ready when alpha work restarts.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

I shortened mine a bit, but left both platform sections for each app.

I did remove 4 of the 5 sections (x2) for CUDA though.

---

In the <name>setiathome_enhanced</name> section, the <plan_class> has a couple of differences in my case than the other similar entries in the other sections.

In the <version_num>610</version_num>, the <plan_class> is cuda_fermi which I think maybe cuda42.

In the <version_num>608</version_num>, the <plan_class> is just plain cuda which I think could be cuda50.

Anyone know for sure or have the secret decoder ring?

Thanks for all the hard work on getting the new app_info info out!

John

---

In the <name>setiathome_enhanced</name> section, the <plan_class> has a couple of differences in my case than the other similar entries in the other sections.

In the <version_num>610</version_num>, the <plan_class> is cuda_fermi which I think maybe cuda42.

In the <version_num>608</version_num>, the <plan_class> is just plain cuda which I think could be cuda50.

Anyone know for sure or have the secret decoder ring?

Thanks for all the hard work on getting the new app_info info out!

John

Not really. The plan classes and version numbers are present to mop up any old stock-issued work that might be lying around, and process all of it using your preferred new application.

The full decoder ring (the secret is revealed on the applications page) reveals:

setiathome v6
v6.08 cuda (actually cuda 2.0)
v6.09 cuda23
v6.10 cuda_fermi (actually cuda 3.0)

setiathome v7
v7.00 cuda22
v7.00 cuda23
v7.00 cuda32
v7.00 cuda42
v7.00 cuda50

But the tasks are all the same (except for the distinction between v6 and v7) - they don't require different cuda levels.

From the Lunatics installer, pick the single application which suits your hardware best. It will process all of the above.

Thanks Richard!

I have looked at the application page before but I didn't recall the relationships documented there, makes it much clearer now.

On my small-seti system I got down to the last two tasks before I 'cleaned up' my app_info.xml file and restarted BOINC, blowing those two off. After that everything started downloading and rebuilding my work cache.

Thanks for pointing me to the answer of my silly questions.

John

---