If you're going to go to the trouble of reinstalling an older version of boinc you may as well give boinctasks a try.
Looks good from what the screenshots show. I'm now completely unsure how to continue with that client, either go back to 6.10.58 or use this software. Had a
quick glance over the manual and it shows there are especially some functions to support high volume clients (caching etc.), which is good but would not apply for my clients.
What I would really appreciate is:
- No "hidden" options (Boinc Manager cc_config.xml), meaning at least the ability to
really turn off the GPU through the user interface (especially when the GPU is an IGP). BM has it in the UI but switching it of there does not work, you must use cc_config for this otherwise GPU wu's will still be requested despite the UI-setting! To put it simple: Full control over GPU usage.
- Same goes for the "report immediately" function (absent in BM UI). If server load is such a problem, offering this function would not make sense at all. My point of view: Casual crunchers to not create very much traffic (but will create "their" automatic traffic anyway), Boinc junkies will work themselves into the configuration options anyway, thus making it quite likely they will use this switch (and they are the people who will
then create much of the traffic/constant server load).
- Ability to user-control the "phone-home" and/or "phone-to" behaviour of the application. Again BM hides it, this includes checking network connectivity, project list refresh, and as of recently news polling (the latter seems not to be controlable at all).
- Ability to force a continuation/completion of wu's on defined conditions (overriding the "switch appliction all xx minutes" option as currently implemented in BM). Example: The most useful condition for me would be to continue computing of a wu if it is already at or above 90%. The managing tool would then not switch applications even if xx minutes are reached. Given the different lenghts of wu's over different projects, there is no point in
only tinkering with the xx minutes switch by increasing or decreasing it (that will only move the problem). This aims for some sort of optimized RAC (over multiple projects). Currently the only option would be to to set xx minutes very high, and thus potentially narrowing computing time to a few projects and possibly creating an unsteady RAC (both aspects seen on a per day base). Severly decreasing xx minutes seems not to be a real option when running multiple (many) projects as you may run into memory problems when using it in combination with the "keep apps in memory" option.
About my current situation:
As expected the client credits are in the process of being merged. One thing I noticed is, the "new" client gets an entry for the top 5 credit days (50+k credits). Obviously this is something I don't want to have on record for this client (want to have "real" numbers there

). As of now it seems I lost the real numbers of the "old" client and get some artificial/wrong numbers on the "new" one which I will not be able to surpass by normal crunching. What will be the end state of this process? One client containing all the credits plus a wrong top 5 list and one empty (0 credits) client containing the correct top 5 list? Or will the empty client be merged into the new one, carrying over the correct top 5 list in the process?