Hey everyone,

I was hopeful that I could get a app_config file that would keep the agent from running one of the two projects or at a minimum keep it only running on 1 core. Both of these options did not work within my testing on a 7.2.x client. The first method did not allow for me to specify a bogus app_class that would prevent one of the two projects from running entirely. the second method basically starved the agent, did not allow for the computer to be utilized 100% while using only 1 core for another project.

I have added this to our list of things to allow for the option to select which of the two science applications for members. It unfortunately is not a high priority right now as we are working towards other items on our list right now.

I am sorry for getting everyone's hopes up as I thought there would have been a way.

Thanks,
-Uplinger

I am back to the simple solution is to list the two types as separate projects and I can't understand what such a simple fix can't be done.

Maybe this will jog, jock or jolt movieman, actually being quite surprised by the development checkin notes implying there's no per-science app credit, but maybe it is meant to also segregate the different platforms, very probable in fact, so e.g. creepy crawly android is not pulling down or distorting averages per second for the linux racehorse, on fahv, or windows cep2 doing better than linux in efficiency.

server: add script to export per-app credit data as XML master
commit
David Anderson [Fri, 15 Aug 2014 23:20:40 +0000]
server: add script to export per-app credit data as XML

Add an official notion of "sub-project": see
http://boinc.berkeley.edu/trac/wiki/PerAppCredit

17 hours agoserver/web: add support for per-application credit
commit
David Anderson [Fri, 15 Aug 2014 21:01:32 +0000]
server/web: add support for per-application credit

See http://boinc.berkeley.edu/trac/wiki/PerAppCredit
If enabled (by the <credit_by_app> config flag)
validators will maintain on a per-(app, user, credit type) basis,
and same for teams,
in new DB tables credit_user and credit_team.
This info is displayed in the web site, on user and team pages,
using project-supplied functions to generate the HTML.

Note: update_stats doesn't decay the recent-average values
for per-app credit; I'll add this if needed.

Glacial speed of addressing this whole borked credit system, to include high runtime variability even at per-app, speak platform level, prince may want to change his famous song to 2099.

But, maybe a piece is already skunkworked into the wcg server code and berkeley doing catch-up. Maybe they, wcg, should rehire keithing reed to exclusively address this as a second job, no distraction for the millepede technicians


(and webpages, well it's glass half empty, another one the berkeley standard will have that wcg won't, not taking bets, just visit the 3rd party stats websites taking in that emphasized bit on exports and the other bolded bit about decaying racs, if you can't get it here ).