Setting so BOINC reports completed WUs instantly?

[DrPop]

I just redid a few computers and realized I've forgotten what to add to make BOINC report the WUs as they finish instead of collecting 30 or so of them up before it reports them. Obviously this setting is needed for close challenges when every WU counts! :)
Thanks for the info.

[Cruncher Pete]

You need to have an app_info.xml for the project that you wish to run and add to it: <report_reuslts_immediately>.

I presume you know how to make an app_info and where to place it. Let me know if not and I will explain...

[Duke of Buckingham]

You need to have an app_info.xml for the project that you wish to run and add to it: <report_reuslts_immediately>.

I presume you know how to make an app_info and where to place it. Let me know if not and I will explain...

You can add the line on cc_config also and that will be to all Boinc projects with no need to make another app_info every time you join a new project. Sometimes is needed for other reasons, like GPU crunching or to simulate more CPUs. Like:

<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
<ncpus>2</ncpus>
</options>
</cc_config>

[Cruncher Pete]

Thanks Duke. That is a better answer.

It might be worthwhile to read: http://www.techpowerup.com/forums/showthread.php?t=174138 as BOINC versions 7.0.42 and above no longer use app_info.xml but app_config.xml. Handy to know especially for those projects that use GPU's.

[Bryan]

Another question, can you use the ncpu command in a app_info/app_config and limit the number of cores/threads that a cpu project uses?

[kmanley57]

Another question, can you use the ncpu command in a app_info/app_config and limit the number of cores/threads that a cpu project uses?

It might work to use:

max_concurrent: This specifies the maximum number of WU the app can run at a time. Best to set this to the number of total HCC1 WU your computer will be doing at a time.

Thus limiting the number of that Cpu project WUs you run. I do not know if you can limit it to run like 4 different cpu only projects and X GPU projects on a machine. But you could do 2 cpu projects running 2 WU each, or 4 running 1 each.

[zombie67]

To be clear:

1) <report_results_immediately>0|1</report_results_immediately>: It is placed in the cc_config.xml (http://boinc.berkeley.edu/wiki/Client_configuration) file. cc_config.xml goes in the BOINC folder, and applies to all projects.

2) app_config.xml (http://boinc.berkeley.edu/trac/wiki/ClientAppConfig) did not replace app_info.xml (http://boinc.berkeley.edu/wiki/Anonymous_platform) (aka anonymous platform). app_config.xml is a simpler way to do some of the things app_info.xml can do, and can be used as an alternative to app_info.xml. At least one project (WCG) will not allow anonymous platform, so app_config.xml was developed as an alternative method to adjust scheduling parameters. app_config.xml requires later versions of 7.0.xx, but I don't recall exactly which one is started with. Both files are project-specific, and must be placed in a project folder under BOINC. I do not believe that you can use both at the same time for a particular project, but I haven't tested that.

[Duke of Buckingham]

Another question, can you use the ncpu command in a app_info/app_config and limit the number of cores/threads that a cpu project uses?

You can use on any Boinc .xml file to expand or limit, the number of CPUs you want to run in a project or in Boinc. The use of more cores than you have will in the end make run more tasks dividing the CPU power for the tasks.

Examples on cc_config:
If in dual core I use 4 ncpus, it will run 4 threads or tasks at the same time.
If I put 1 ncpu it will use only one core, saving the other for domestic use.

Examples on app_info/app_config:
Takes all the CPU power to the project as long you have enough tasks to run.
Limits the use of the project to the amount of cores that you say the project can use, the others will run other Boinc projects.

I hope that was clear enough, my English sometimes is not enough on this technical issues.

[Duke of Buckingham]

To be clear:

1) <report_results_immediately>0|1</report_results_immediately>: It is placed in the cc_config.xml (http://boinc.berkeley.edu/wiki/Client_configuration) file. cc_config.xml goes in the BOINC folder, and applies to all projects.

2) app_config.xml (http://boinc.berkeley.edu/trac/wiki/ClientAppConfig) did not replace app_info.xml (http://boinc.berkeley.edu/wiki/Anonymous_platform) (aka anonymous platform). app_config.xml is a simpler way to do some of the things app_info.xml can do, and can be used as an alternative to app_info.xml. At least one project (WCG) will not allow anonymous platform, so app_config.xml was developed as an alternative method to adjust scheduling parameters. app_config.xml requires later versions of 7.0.xx, but I don't recall exactly which one is started with. Both files are project-specific, and must be placed in a project folder under BOINC. I do not believe that you can use both at the same time for a particular project, but I haven't tested that.

In contradictory instructions the computer always uses the last and the last should be the app_config before of that the app_info and before of that the cc_config. If computing laws still apply that should be it but I never tested also.

:(( Sorry for posting immediately after you Z, the forum doesn't say nothing about other posts in the same thread when we are about to post. In some others there is a warning message.

[Bryan]

So app_config works with BOINC 7.0.4xx and higher. Is there one of the newer versions that is actually somewhat stable? I'm doing CPU crunching only.

[nanoprobe]

So app_config works with BOINC 7.0.4xx and higher. Is there one of the newer versions that is actually somewhat stable? I'm doing CPU crunching only.
app_config works only with versions 7.0.42 and above. I'm currently using 7.0.56 and it's very stable but there are now newer versions out. As an FYI you can't use an app_info file in the versions of BOINC above 7.0.42. Your tasks will complete and upload but they will not report. The app_config system is 100x easier anyway so I would recommend updating your BOINC client and using it.


I do not know if you can limit it to run like 4 different cpu only projects and X GPU projects on a machine.
Yes, you can do that. You can run as many different CPU projects as you have CPU cores available or you can split your cores up to run CPU and GPU tasks simultaneously from different projects.

Another bonus of updating to client 7.0.55 and above is that you can modify the app_config files on the run and not have to shut down and restart BOINC every time you make a change or add an app_config file to a project. Just go the the BOINC manager and select Advanced>Read config file.

[Bryan]

So if you have optimized apps (executables) that would normally be defined and called out in an app_info would you do the same thing in the app_config?

[zombie67]

As an FYI you can't use an app_info file in the versions of BOINC above 7.0.42. Your tasks will complete and upload but they will not report. The app_config system is 100x easier anyway so I would recommend updating your BOINC client and using it.

This is not correct. app_info.xml still works as it used to with 7.0.42+.

[zombie67]

So if you have optimized apps (executables) that would normally be defined and called out in an app_info would you do the same thing in the app_config?

Custom apps require anonymous platform (app_info.xml).

app_config.xml is *only* for custom scheduling options.

[Bryan]

@Z ... so I'm assuming you can run both the app_info AND app_config on the same project. So that brings up the question that if max_concurrent is defined can it be used in the app_info or only in the app_config?

[zombie67]

@Z ... so I'm assuming you can run both the app_info AND app_config on the same project. So that brings up the question that if max_concurrent is defined can it be used in the app_info or only in the app_config?

I don't know if both can be used at the same time, for the same project. See my earlier post:


I do not believe that you can use both at the same time for a particular project, but I haven't tested that.

There is nothing added to the wiki for the app_info.xml about max_concurrent. But that doesn't mean it hasn't been added to the functionality. BOINC documentation sucks out loud.

[nanoprobe]

So if you have optimized apps (executables) that would normally be defined and called out in an app_info would you do the same thing in the app_config?

You don't need any executables in the app_config file. All you need is the correct app name which you can find in the client_state.xml file found in the BOINC folder. If you run or have run a lot of projects that folder could be large but the needed info is in there. Here are some examples.

app_config for WCG. As you can see there are no executables, only the correct app name. The max_concurrent tag is only needed for CPU tasks. The gpu_uasge tag controls how many tasks you want your GPU to run. You can put 1 or all of the WCG projects into 1 config file. Only the tasks you have selected on your profile page on the WCG site to run will download and run. The rest of the info in the config file will be ignored. This goes for any project that might have more than 1 app available. The GPU part of this config file will run 8 GPU tasks using 4 CPU cores. You can use partial cores only if you have an ATI card. Nvidia driver support for OpenCl is not very good and requires a full core for each GPU task and you'll probably not be able to run more than 4 tasks simultaneously depending on the model of your card, again because of poor driver support. (From info I've gathered from other Nvidia owners you'll probably not be able to run no more than 2 tasks at a time @WCG)

<app_config>
<app>
<name>hcc1</name>
<gpu_versions>
<gpu_usage>.125</gpu_usage>
<cpu_usage>0.50</cpu_usage>
</gpu_versions>
</app>
<app>
<name>beta</name>
<max_concurrent>8</max_concurrent>
</app>
<app>
<name>sn2s</name>
<max_concurrent>4</max_concurrent>
</app>
<app>
<name>c4cw</name>
<max_concurrent>1</max_concurrent>
</app>
</app_config>

app_config for SkynetPogs

<app_config>
<app>
<name>magphys_wrapper</name>
<max_concurrent>2</max_concurrent>
</app>
</app_config>

This will run the app on 2 of my available 8 cores. As you can see the app name is quite different than the project name. That's why it is important to have the correct name in your app_config file. Since I'm only using 2 of my 8 cores I can run other projects on the other cores by placing an app_config into the correct project folder. If you have 8 cores you could run 8 different CPU projects at a time by assigning 1 core to each project. Just be advised that running that many could take a lot of monitoring. I have run 4 different ones at the same time. Keeping the caches full does take some looking after because of priority settings.

Hope I haven't totally confused you. I'll be glad to answer any questions you have. Once you get the hang of this you'll see how much easier it is to use an app_config over an app_info.

[DrPop]

Thanks guys! That was the one I was thinking of. And now you're getting way over my head so I'll turn the thread over to Bryan and ya'll. ;)

[nanoprobe]

This is not correct. app_info.xml still works as it used to with 7.0.42+.

OK. My bad. It didn't work @ WCG so I assumed wrong that it wouldn't work anywhere else.

[zombie67]

OK. My bad. It didn't work @ WCG so I assumed wrong that it wouldn't work anywhere else.

Right, that get's back to my earlier comment:


At least one project (WCG) will not allow anonymous platform, so app_config.xml was developed as an alternative method to adjust scheduling parameters.

Projects have the ability to dis-allow anonymous platform (app_info.xml). WCG is not allowing it, and there may be others in the future. But the functionality still remains in the BOINC client and server for anonymous platform.

And anonymous platform is still the only way to use custom apps. So app_config.xml is not a replacement for anonymous platform.

[nanoprobe]

And anonymous platform is still the only way to use custom apps. So app_config.xml is not a replacement for anonymous platform.

Could you explain this in more detail. I'm confused as to where an app-config cannot replace an app_info.

[Duke of Buckingham]

AppConfig
is a Perl5 module for managing application configuration information. It maintains the state of any number of variables and provides methods for parsing configuration files, command line arguments and CGI script parameters.

Variables values may be set via configuration files. Variables may be flags (On/Off), take a single value, or take multiple values stored as a list or hash. The number of arguments a variable expects is determined by its configuration when defined.


AppInfo
I didn't know about it before IPhones and IPads, it seems thought to be somehow redundant and is only in use at Boinc because of some projects that choose not to use the AppConfig.

There are several (more or less) technical explanations about it on the web, I like this one for being more complete: http://pic.dhe.ibm.com/infocenter/esbsoa/wesbv7r5/index.jsp?topic=%2Fcom.ibm.websphere.wesb.programm ing.doc%2Ftopics%2Ftbopg_annot.html

I don't think there is any easy explanation about it anyway. The use of config files comes from the start of computers and have a lot things that have no meaning anymore, mainly adapting the hardware to software on a time (beginning of DOS) that Microsoft was just a dream and most laugh of Bill Gates statements that software would be more important than hardware.

[Bryan]

Could you explain this in more detail. I'm confused as to where an app-config cannot replace an app_info.

I think he is referring to the question I asked earlier. If you have optimized executables (.exe files) and .dll that are NOT the stock program issued by the project then you must tell BOINC which program to run for the project. This is done with the app_info.xml file.

For example, I have optimized apps that give 3X the credits of the stock GSCE program on Oproject. The app_info looks like this:

<app_info>
<app>
<name>gsce-sv</name>
<user_friendly_name>GSCE-SV</user_friendly_name>
</app>

<file_info>
<name>gsce_boinc_windows_x86_64_I7.exe</name>
<executable/>
</file_info>

<app_version>
<app_name>gsce-sv</app_name>
<version_num>105</version_num>
<platform>windows_x86_64</platform>
<avg_ncpus>1.000000</avg_ncpus>
<max_ncpus>1.000000</max_ncpus>
<flops>1954031431.285427</flops>
<api_version>7.1.0</api_version>
<file_ref>
<file_name>gsce_boinc_windows_x86_64_I7.exe</file_name>
<open_name>gsce_boinc_windows_x86_64_I7.exe</open_name>
<main_program/>
<copy_file/>
</file_ref>
</app_version>


</app_info>

[nanoprobe]

I think he is referring to the question I asked earlier. If you have optimized executables (.exe files) and .dll that are NOT the stock program issued by the project then you must tell BOINC which program to run for the project. This is done with the app_info.xml file.

For example, I have optimized apps that give 3X the credits of the stock GSCE program on Oproject. The app_info looks like this:

<app_info>
<app>
<name>gsce-sv</name>
<user_friendly_name>GSCE-SV</user_friendly_name>
</app>

<file_info>
<name>gsce_boinc_windows_x86_64_I7.exe</name>
<executable/>
</file_info>

<app_version>
<app_name>gsce-sv</app_name>
<version_num>105</version_num>
<platform>windows_x86_64</platform>
<avg_ncpus>1.000000</avg_ncpus>
<max_ncpus>1.000000</max_ncpus>
<flops>1954031431.285427</flops>
<api_version>7.1.0</api_version>
<file_ref>
<file_name>gsce_boinc_windows_x86_64_I7.exe</file_name>
<open_name>gsce_boinc_windows_x86_64_I7.exe</open_name>
<main_program/>
<copy_file/>
</file_ref>
</app_version>


</app_info>

Interesting. Thanks for the explanation. How did you ever figure out how to construct the app_info to give you the desired results at Oproject?

[zombie67]

Could you explain this in more detail. I'm confused as to where an app-config cannot replace an app_info.

Check out the pages I linked to in the earlier post. I included them again below. In short, app_info.xml is for running your own executables, and also allows you to set custom scheduling parameters. app_config.xml uses the stock apps from the project server, it is only for changing scheduling parameters.

app_info.xml (AKA anonymous platform) (http://boinc.berkeley.edu/wiki/Anonymous_platform)

BOINC applications are native-mode programs, so different versions are required for each platform (a "platform" is the combination of an operating system and a CPU architecture: e.g., Linux/Intel32). Each BOINC-based project has application versions for one or more platforms. When the BOINC client requests work from the project's server, the client tells the server its platform, and the server gives it the appropriate version.
This addresses the needs of most BOINC participants, but it's inadequate if:

your computers have platforms not supported by BOINC or by the project;
for security reasons, you want to only run executables you have compiled yourself;
you want to optimize applications for particular architectures.


To handle these cases, BOINC offers a mechanism called anonymous platform. This lets you build applications yourself, or obtain them from a third party, rather than getting them from the project server. This can be used only for projects that make their source code available.


app_config.xml (http://boinc.berkeley.edu/trac/wiki/ClientAppConfig)

This doc describes a new feature that will allow volunteers to adjust application scheduling parameters.

Note: this is separate from the anonymous platform mechanism.

A volunteer can configure a project's apps by putting a file app_config.xml in the project's directory.

[nanoprobe]

I saw at Oproject that they have some optimization apps depending onn your CPU. I'll have to play with that some day. Thanks again

[Slicker]

To return results immediately, you need to use an older BOINC client. DA "fixed" it and took away the return_results_immediately in recent 7.x versions. You will see in the event log when BOINC starts that the return_results_immediately setting is not recogniuzed.

[Bryan]

To return results immediately, you need to use an older BOINC client. DA "fixed" it and took away the return_results_immediately in recent 7.x versions. You will see in the event log when BOINC starts that the return_results_immediately setting is not recogniuzed.

So in a challenge I guess we need to run "Updater" :D

[Bryan]

I saw at Oproject that they have some optimization apps depending onn your CPU. I'll have to play with that some day. Thanks again

I have posted 3 sets of Intel optimized apps that give 3X credits over stock. They are for I7s, Core 2 quads, and E53xx/54xx Xeons. F$ setup an account on Dropbox.com where you can download them. The apps work on GSCE only.

[zombie67]

To return results immediately, you need to use an older BOINC client. DA "fixed" it and took away the return_results_immediately in recent 7.x versions. You will see in the event log when BOINC starts that the return_results_immediately setting is not recogniuzed.

Yeah, I saw that too. But I think maybe he put it back in. Here 7.0.58:


484 4/4/2013 1:17:35 PM Re-reading cc_config.xml
485 4/4/2013 1:17:35 PM Not using a proxy
486 4/4/2013 1:17:35 PM Config: report completed tasks immediately
487 4/4/2013 1:17:35 PM Config: use all coprocessors
488 4/4/2013 1:17:35 PM Config: GUI RPC allowed from any host
489 4/4/2013 1:17:35 PM log flags: file_xfer, sched_ops, task, sched_op_debug

No error message.

[Slicker]

So in a challenge I guess we need to run "Updater" :D

All the updaters do is bypass boinc manager and call the update command on the boinc client. DA changed the client. So, even the updater won't do anything unless they've changed it back. But I doubt it. If the project isn't using OpenCL, my suggestion is to go back to a 6.6.x version.

[Bryan]

While I've got you on the line Slicker, I wanna ask a question about credit new the random credit generator. It appears when you first start a project it grants above normal credits until the server figures out the machine. Say I've stabilized on my credits and I uninstall BOINC ... totally and then reinstall it. Will the project see the machine as a "new" machine or will it somehow figure out that it is the same machine?