People, you can stop PMing me with requests that I forward all your enhancement request information to the developers. I already did that mostly based on the contents of this thread.

Could you summarise what requests you've received, please?

I do wish people would post in public on the boards - when everything is done through secret back-channels, the rest of us don't know what would be a duplicate request/report, and what might be new. (That isn't a criticism of you, Jord - I appreciate your role as a filter/firewall protecting the staff from the raw undigested flood of user feedback: but I do think bugs/problems/wish lists should be aired for peer comment and review).

For my part, I suspect that the new features - especially fractional GPU usage - still need to be hooked up to the runtime estimation and work fetch processes, but I need to study them in more detail before I can make a proper report.

One thing I'm testing is to not process a science that might slip through the due the "If there is no work for your selection, send me something else". Possible scenarios are a project that always fails on a specific device or is really to plain heavy. Is <max_instances>0</max_instances> going to stop the execution [on CPU, GPU or both], or is 0 as so often interpreted as "no restriction"?

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

[Off-topic], thought the thread owner could edit the title and am sure I saw some instruction [to e.g. insert [RESOLVED], but beat me, either editing a post or appending a post, can't get the title to turn into edit mode.[/Off-topic]

[Off-topic], thought the thread owner could edit the title and am sure I saw some instruction [to e.g. insert [RESOLVED], but beat me, either editing a post or appending a post, can't get the title to turn into edit mode.[/Off-topic]

Make a new stand-alone post in the thread (not a reply or quote): then edit the new post.

People, you can stop PMing me with requests that I forward all your enhancement request information to the developers. I already did that mostly based on the contents of this thread.

Could you summarise what requests you've received, please?

As I said, mostly what's been asked for in this thread as well, the option to re-read all config files from BM.

Added to that the request for some better documentation, including where to find all of the specific parts of what the app_config.xml file needs. Or add a warning that it's to be used by Super Über Extremely Advanced Power users only. ;-)

And have the documentation in one place only. There's nothing as confusing as having the same documentation in two places and both differing from each other.

---

Beat me, miracles, I just gave a sample of [RESOLVED], and low behold, the title changed to something I'd not wanted to change it to. "7.0.40-42" was the plan. At any rate, tried "Post to Thread", but it would not either, so not sure what "standalone-post" is, but will let it be.[/Off-topic]

On short names, some members had trouble identifying what the legal ones were, so on WCG side, asked for a column addition to the System Requirement page, which currently shows the "user_friendly" names. Many places to find them, but if we add an official feature, dotting the i well close that gap [of course, who's going to look in system requirements ;>)

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

At any rate, tried "Post to Thread", but it would not either, so not sure what "standalone-post" is, but will let it be.[/Off-topic]

Try editing your message 46771 - that was what I meant by stand-alone.

If you can't edit the title at the same time as editing the post, then the message board software has developed a bug since last time I tried it (some years ago).

OK, either it was a bug that went sailing, or more probable, I just could not see it till now. The Title box appeared with this last post and changed title, to indicate the discussion covers multiple test versions

edit: It has to be a new post... editing a post does not show the option.[/off-topic]

edit2: As suspected setting <max_concurrent> to zero is equal no-limit. It would be nice to have a value that stops unwanted that slipped through the "if there is no work..." mazes, to not run for the said reasons, either too heavy, or always/large proportion failing.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

I edited your title with [RESOLVED] to the end. As I figured that that was what you wanted when you gave it as an example. So no bug, just a nosy moderator in the way. ;-)

---

I have not used app_config.xml yet as I am still on 7.0.28. However, I was wondering if there will be a get_app_config and set_app_config rpc call like the get and set cc_config? BTW, I dont see the set_cc_config documented it the rpc wiki but that is a separate problem.

The reason I was asking was I was thinking it would be nice if the set and get cc_config rpc calls could be used to obtain (read) and be able to update the app_config and the app_info files. Seeing as both go into the project directories it seems a convenient way to update any of them.

For Example --

I was advised at the project POEM that if I wanted to run POEM on a system that had two nVidia (or ATI) boards and not get constant "restart" errors (they claim a boinc bug) that I need to add XXX to cc_config and YYY to app_info (refer to thread above for the XXX and YYY)

Anyway, some of my systems are headless and I use BOINCTASKS which can retrieve cc_config.xml, allow edits, and update it all using rpc calls.

It would be nice to have app_info and app_config sections in "cc_config" to allow Fred's program to update those xml files.

my 2c.


[EDIT]
1. get_cc_config would obtain each (if any) app_info and app_config from each project directory and put it into a a new section "ExternalAppsXML" in cc_config. The corresponding set_cc_config would store the contents of that "ExternalAppsXML" section at the corresponding project locations (listed in that file) or something like this :-)

However, I was wondering if there will be a...

No, there will not be such a thing, nor will there be a menu option to re-read the app_config.xml file. I have just learned that the developers feel that the app_config.xml file is a temporary thing, while projects learn how to parametrize their GPU apps.

---

I had a further discussion with David on this:

David wrote:

The goal is to not add more preferences, but to have the project's scheduler figure out the best number of jobs per GPU.

Jord wrote:

Without the user having any say in it?
Just asking, as my GPU is capable of running 4 Einstein tasks at a time, but I'd rather only run 1. So some form of control would be appreciated.
And what about system where there are more than one GPU in the system, not necessarily all capable of running more than one task?

What I like about the app_config.xml file is that I can now control how much CPU the Einstein app can take at max. If left to its own, it'll take slightly over half of a CPU core. I however set it to use .25 of the CPU and it does so, without too much of a slow-down.

So some form of user-control is always desired.

David wrote:

The goal is for BOINC to automatically figure out the optimal number of jobs per GPU. Of course we'll keep the app_config mechanism for people who want to fiddle with it manually. But I don't want to add any GUI for this purpose.

Which makes more sense. :-)

---

What I was looking for was not a gui change but just another RPC call such as

get_project_file("www.worldcommunitygrid.org","app_config.xml", char* etc

or

set_project_file("boinc.fzk.de_poem","app_data.xml",char* etc

However, over at boinctasks, Fred just posted that something like this had already been rejected.

I can always share project folders across a network for drag and drop, but IMHO boinctasks could easily handle this and be convient and safe if the rpc was available.

Even if there's no GUI (I very rarely use the GUI for cc_config.xml, I prefer to edit it manually), it would be nice if app_config.xml could be read and acted upon while BOINC is running - the same as (most tags in) cc_config.xml, and global_prefs_override.xml

I appreciate that some changes introduced via cc_config.xml (use/don't use all GPUs, for instance) are significant enough to justify a full restart, but I think the changes which can be controlled by app_config.xml (so far) are simple enough that the core client could accept them dynamically.

I agree with David for once. The goal is to get the projects to paramaterize their GPU apps correctly and that is a sound goal from every perspective. If too many easy workarounds are provided then the projects won't paramaterize correctly. Then you have users wandering around looking for the right way to implement the workaround. Nope. The admins can RTFM too and do their jobs instead of expecting us to always pick up after their laziness. (Doesn't apply to all admins but does apply to many, give 'em an inch and they'll take a mile).

1)Even if there's no GUI (I very rarely use the GUI for cc_config.xml, I prefer to edit it manually), it would be nice if app_config.xml could be read and acted upon while BOINC is running - the same as (most tags in) cc_config.xml, and global_prefs_override.xml

2)I appreciate that some changes introduced via cc_config.xml (use/don't use all GPUs, for instance) are significant enough to justify a full restart, but I think the changes which can be controlled by app_config.xml (so far) are simple enough that the core client could accept them dynamically.

FAIK, that's been requested several times to include in this thread and in the pipeline, either a separate option or integrated with the "read config" on the advanced menu.

A future client will certainly have an RPC to transmit the app_config.xml content back to the project [request WCG], so their schedulers can act upon that information, such as when there's a <max_concurrent> of e.g. 4 only a limited set, by some multiplier would be assigned to a host for that science...with a multiplier of e.g. 4 that would mean the host gets 16 maximum. My preferences would be to have an <in_progress> option for the app_config for each science and then have local control of how many a science is send/queued at any time. For an umbrella project like WCG with 10 sciences, it would also stop too much being send of one science when another is temp out of work. A x-rated dream for the micro managers :D

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

One thing I'm testing is to not process a science that might slip through the due the "If there is no work for your selection, send me something else". Possible scenarios are a project that always fails on a specific device or is really to plain heavy. Is <max_instances>0</max_instances> going to stop the execution [on CPU, GPU or both], or is 0 as so often interpreted as "no restriction"?

A workaround I've thought of is to set the cpu_usage or gpu_usage tag to a number higher than the number available in the system, say 10 on a quad-core system. That way the scheduler would never find enough cpus to run it. But I understand these tags are only available for gpu apps as of now?

I can't figure out how to fix this problem. I have both a nvidia and ati/amd card and I have set cc_config to only allow ati to process HCC1 task but it keeps retrieving nvidia tasks, despite it being excluded (see log below).

I am using 7.0.44 with the following configs:

app_config.xml: (only revelant section shown)
<app>
<name>hcc1</name>
<max_concurrent>6</max_concurrent>
<gpu_versions>
<gpu_usage>0.166</gpu_usage>
<cpu_usage>0.334</cpu_usage>
</gpu_versions>
</app>


cc_config.xml: (only revelant section shown)
<exclude_gpu>
<url>http://www.worldcommunitygrid.org</url>
[<type>nvidia</type>]
</exclude_gpu>


LOG:
2/5/2013 7:44:37 PM | World Community Grid | Config: excluded GPU. Type: nvidia. App: all. Device: all

Despite those configs its keeps asking for nvidia and ati task.
2/5/2013 7:45:11 PM | World Community Grid | Requesting new tasks for CPU and NVIDIA and ATI


I only want ATI and CPU tasks yet it keeps asking for nvidia so is there a way to specifiy in the app_config.xml file to get only ATI tasks like we used to in app_info.xml?

Question, does your cc_config.xml contain that piece of the exclude_gpu as you show it?

<exclude_gpu>
<url>http://www.worldcommunitygrid.org</url>
[<type>nvidia</type>]
</exclude_gpu>

I ask as the XML that BOINC uses won't know what to do with those square brackets and so it'll throw an error and not use anything in between them.
So make sure that your code looks like this:

<cc_config>
<log_flags>
</log_flags>
<options>
<exclude_gpu>
<url>http://www.worldcommunitygrid.org</url>
<type>nvidia</type>
</exclude_gpu>
</options>
</cc_config>

but it keeps retrieving nvidia tasks, despite it being excluded (see log below).

2/5/2013 7:45:11 PM | World Community Grid | Requesting new tasks for CPU and NVIDIA and ATI

All that you show us from your log is that work is being asked for Nvidia, not whether or not your BOINC still gets it from WCG. So, does it? Show that part of the log, or show that it's actually working on the Nvidia tasks, or that they are in your cache.

I only want ATI and CPU tasks yet it keeps asking for nvidia so is there a way to specifiy in the app_config.xml file to get only ATI tasks like we used to in app_info.xml?

The app_config.xml file allows you to specify which applications can run with which parameters. It's not there to tell BOINC which piece of hardware it should or shouldn't ask work for.

---

Its in the cc_config exactly as shown. Which is what is on the wiki site for it. I don't get any red error messages and as shown in the log it says its excluding nvidia (see below). If I take the brackets off (what someone else gave me too) then I get the red error message saying it can't parse exclude command. I found it odd too but that what wiki says to do for the command now. Its in the middle of this page:
http://boinc.berkeley.edu/wiki/Client_configuration

With bracket as shown I get this:
2/5/2013 7:44:37 PM | World Community Grid | Config: excluded GPU. Type: nvidia. App: all. Device: all

But it asks for nvidia work and worse it does it, even stopping ATI work and running nvidia instead. I have a max of 6 set in the app_config file so sometimes it does a mix of some on ati and some on nvidia or sometimes just one or the other. Its leans heavily towards nvidia, especially in downloading because I guess no one does that. I got tired of aborting them so I switched back to 7.0.28 and using that app_info file it stops nvidia. I really like the newer versions and want to run them but until someone can come up with a solution its easier running the older version. If you got some ideas, I'll be more than happy to test them.