Hi everyone,

I wanted to throw an idea out there for a feature that would be a huge quality-of-life improvement for high-end hardware users: implementing a web-based GPU usage factor (or concurrency control) directly in the project preferences.

As many of you running modern discrete GPUs or high-core iGPUs probably know, running just 1 task at a time often severely underutilizes the hardware. Right now, the only way around this on projects like NumberFields@Home is messing with local app_config.xml files, which is clunky and inaccessible for a lot of users.

Projects like Einstein@Home and the newer BitBOINC have solved this elegantly by letting users adjust a simple decimal factor on the website account preferences page (e.g., setting it to 0.1 or 0.25 to automatically scale up concurrent tasks).

Implementing something similar on the NumberFields backend would prevent GPU underutilization, make participation much friendlier, and give a massive compute throughput boost to the project.

What do you all think?

What is your GPU utilization?

An app_config works just fine

Do you know how Einstein does it? It's more than just putting on option in the account preferences, because the value somehow gets passed to the client. Or maybe the hooks are already in the BOINC web/client code? I haven't upgraded the server in years.

Do you know how Einstein does it? It's more than just putting on option in the account preferences, because the value somehow gets passed to the client. Or maybe the hooks are already in the BOINC web/client code? I haven't upgraded the server in years.

It's all server-side; the client already supports it. The scheduler tells the client how much of a GPU each app version uses (the <coproc><count> in the app_version it sends), and the client runs 1/count tasks per GPU. So you only need to (1) store a per-user factor in the project prefs and (2) multiply the GPU usage by it in the scheduler. Here is exactly what we did on BitBOINC.

1) Web: project-specific preference (html/project/project_specific_prefs.inc)
Add a field following the same pattern as the existing ones (default / edit / parse_form / show / parse):

// default
$x .= "<gpu_usage_factor>1.0</gpu_usage_factor>\n";

// edit form row
$y = "<input size=6 name=gpu_usage_factor value='$prefs->gpu_usage_factor'>";
tooltip_row2("Lower = more tasks at once on the same GPU", "GPU usage factor (0.5 = 2 tasks, 0.25 = 4 tasks)", $y);

// parse_form (validate!)
$f = get_str("gpu_usage_factor");
if (!verify_numeric($f, 0.01, 1.0)) { $error->gpu_usage_factor = true; $f = 1.0; }
$x .= "<gpu_usage_factor>$f</gpu_usage_factor>\n";

// parse (fall back to 1.0 on anything odd)
$v = (string)$p->gpu_usage_factor;
$prefs->gpu_usage_factor = ($v !== '' && is_numeric($v) && $v > 0 && $v <= 1.0) ? $v : '1.0';

2) Scheduler: parse it (sched/sched_types.h and .cpp)

// sched_types.h, struct PROJECT_PREFS
double gpu_usage_factor; // set to 1.0 in the constructor / clear()

// sched_types.cpp, PROJECT_PREFS::parse()
double f;
if (parse_double(buf, "<gpu_usage_factor>", f) && f > 0 && f <= 1.0) {
gpu_usage_factor = f;
} else {
gpu_usage_factor = 1.0;
}

3) Scheduler: apply it where gpu_usage is computed
If you use plan_class_spec.xml: in PLAN_CLASS_SPEC::check() (sched/plan_class_spec.cpp), right after gpu_usage is set:

if (g_wreq && g_wreq->project_prefs.gpu_usage_factor > 0
&& g_wreq->project_prefs.gpu_usage_factor <= 1.0) {
gpu_usage *= g_wreq->project_prefs.gpu_usage_factor;
}

If your GPU plan classes are hard-coded in sched_customize.cpp (older servers), do the same multiplication on hu.gpu_usage in the app_plan function(s) for your GPU plan classes, just before returning true.

Gotcha: the prefs are NOT reachable through the SCHEDULER_REQUEST (sreq). They live in the global WORK_REQ: g_wreq->project_prefs (declared in sched_types.h). You may need #include "sched_types.h" in plan_class_spec.cpp.

4) Rebuild and deploy
In sched/: make cgi (or a full make), back up the old cgi-bin/cgi, and copy the new one over. No daemon restart is needed.

Notes
- Default 1.0 = exactly today's behaviour for everyone who doesn't touch it.
- It takes effect on the user's next scheduler request that sends work (the client takes the count from the app version in the reply).
- We added a matching cpu_usage_factor the same way (multiplying hu.avg_ncpus), for hosts where a GPU task uses more CPU than declared.

Feel free to ask if you need any help; I can assist you. I am currently reviewing your GPU code at the request of a volunteer; it appears I can cut the processing time in half—or even more. Once I have made the necessary fine-tuning and achieved satisfactory results, I will share the code with you so that you can review it in your spare time and use it as a new version, or so that people can run it as an anonymous application.

---

The project does not support anonymous applications; please enable this.

The project does not support anonymous applications; please enable this.

Since there is only 1 Task per WU it would be a risk i think.
There should be enough test files in the repo to test own applications

This looks like a substantial change to the code and I will probably have to update to the latest server code before even attempting it. So I am going to put it on the back burner for now. Users have the option to use the app_config mechanism as a work around, so this is not high priority at the moment.

The project does not support anonymous applications; please enable this.

Since there is only 1 Task per WU it would be a risk i think.
There should be enough test files in the repo to test own applications

I agree with Stiwi, this is not safe. I can always get you more test WUs if you need them.

But I look forward to seeing if you can optimize the GPU code. I think it will come down to a faster multi-precision integer library.

The project does not support anonymous applications; please enable this.

Since there is only 1 Task per WU it would be a risk i think.
There should be enough test files in the repo to test own applications

I agree with Stiwi, this is not safe. I can always get you more test WUs if you need them.

But I look forward to seeing if you can optimize the GPU code. I think it will come down to a faster multi-precision integer library.

Please allow the anonymous platform, which is limited to 25 work units per day, because I need to test it with the actual BOINC client.

You can review the code and applications here. If you can provide server access, I can fully modernize the project within two days, if you wish.
https://github.com/alplix/passiflora

Tested in rtx5070ti + i513400f

Work unit                         Stock CPU   Passiflora CPU (1 core)   Stock GPU   Passiflora GPU
--------------------------------  ----------  ------------------------  ----------  --------------
sf3_DS-16x270_Grp74of3932160      1727 s      72 s                      62.4 s      5.6 s
sf3_DS-16x271-1_Grp99of2000000    508 s       45 s                      25.3 s      7.2 s
sf5_DS-16x12_Grp90of1600000       ~1700 s     93 s                      80.2 s      5.1 s
sf6_DS-7x10_Grp16925of160000      -           14-16 s                   13.1 s      1.5 s

---

BOINC server allows project admin to configure beta testing https://github.com/BOINC/boinc/wiki/BetaTest if one needs more samples to verify that the custom/anonymous application is working fine before putting into production. In this way, one can run hundreds or thousand of tasks easily to increase confidence that the new apps is working on a range of different hardware and OSes as specified by the application. As usual, the boinc volunteer will have to manually check the beta testing checkbox in the project preferences to opt in. A quorum of at least two is good to check stock app against custom/anonymous app for potential discrepancy, if any.

Please allow the anonymous platform, which is limited to 25 work units per day, because I need to test it with the actual BOINC client.

You can review the code and applications here. If you can provide server access, I can fully modernize the project within two days, if you wish.
https://github.com/alplix/passiflora

Tested in rtx5070ti + i513400f

Work unit                         Stock CPU   Passiflora CPU (1 core)   Stock GPU   Passiflora GPU
--------------------------------  ----------  ------------------------  ----------  --------------
sf3_DS-16x270_Grp74of3932160      1727 s      72 s                      62.4 s      5.6 s
sf3_DS-16x271-1_Grp99of2000000    508 s       45 s                      25.3 s      7.2 s
sf5_DS-16x12_Grp90of1600000       ~1700 s     93 s                      80.2 s      5.1 s
sf6_DS-7x10_Grp16925of160000      -           14-16 s                   13.1 s      1.5 s

I looked into the anonymous platform, and apparently it is automatically enabled. But it wont work if apps are already deployed for the OS/platform being tested. It looks like I need to create a special test application but not deploy any executables. The user then handles the anonymous platform on the client side via the app_info.xml. I will create this test app soon.

The timing data is impressive! I looked at your link. I'll need to spend more time thinking about it, but it looks like some clever manipulations in the polynomial discriminant calculation.

Thanks for the offer to upgrade the server, but I'm pretty sure that goes against the department's security regulations. I just need to get off my butt and do it.

BOINC server allows project admin to configure beta testing https://github.com/BOINC/boinc/wiki/BetaTest if one needs more samples to verify that the custom/anonymous application is working fine before putting into production. In this way, one can run hundreds or thousand of tasks easily to increase confidence that the new apps is working on a range of different hardware and OSes as specified by the application. As usual, the boinc volunteer will have to manually check the beta testing checkbox in the project preferences to opt in. A quorum of at least two is good to check stock app against custom/anonymous app for potential discrepancy, if any.

If you were to enable beta testing here, i'd be happy to give a couple of my machines a go on Beta to help out.

Send out batches of Tasks of all types that have already been completed, so you can compare the existing results with the returned Beta results.

---

Grant
Darwin NT, Australia.

I looked into the anonymous platform, and apparently it is automatically enabled. But it wont work if apps are already deployed for the OS/platform being tested. It looks like I need to create a special test application but not deploy any executables. The user then handles the anonymous platform on the client side via the app_info.xml. I will create this test app soon.

The timing data is impressive! I looked at your link. I'll need to spend more time thinking about it, but it looks like some clever manipulations in the polynomial discriminant calculation.

Thanks for the offer to upgrade the server, but I'm pretty sure that goes against the department's security regulations. I just need to get off my butt and do it.

I created the new app "testDecics". It has no platforms defined, so should work with the anonymous platform. I also generated 100 WUs for it.

Unfortunately, it is still rejecting it with the same error.

I created the new app "testDecics". It has no platforms defined, so should work with the anonymous platform. I also generated 100 WUs for it.

According to the server status page https://numberfields.asu.edu/NumberFields/server_status.html, the 100 test WUs are still unsent.

FYI, in my project preferences, I checked the box "Run test applications" and in the field "Run only the selected applications", I only click on the box "Decic Field Testing: yes" The Boinc Manager event log says "No tasks are available for Decic Field Testing"

10/9/2026 6:21:48 AM | NumberFields@home | Sending scheduler request: To fetch work.
10/9/2026 6:21:48 AM | NumberFields@home | Requesting new tasks for CPU and NVIDIA GPU
10/9/2026 6:21:49 AM | NumberFields@home | Scheduler request completed: got 0 new tasks
10/9/2026 6:21:49 AM | NumberFields@home | No tasks sent
10/9/2026 6:21:49 AM | NumberFields@home | No tasks are available for Decic Field Testing
10/9/2026 6:21:49 AM | NumberFields@home | Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
10/9/2026 6:21:49 AM | NumberFields@home | Tasks for Intel GPU are available, but your preferences are set to not accept them
10/9/2026 6:21:49 AM | NumberFields@home | Project requested delay of 121 seconds

I have never used the anonymous platform before. I was basing my responses on this:
https://github.com/BOINC/boinc/wiki/Anonymous-platform
Did you follow these instructions regarding the app_info.xml:

To use the anonymous platform mechanism for a particular project:
    1.  Get the project's application source code and compile it, or download an executable from a third party.
    2.  Run the BOINC client and attach to the project. This will create a 'project directory' (whose name is the project URL) in the BOINC directory. Exit the client. Put your executables in the project directory (Mac OS X users: see note below).
    3.  Create a file app_info.xml in the project directory. This file describes the applications you have compiled or downloaded. Its format is described below.
    4.  Run the BOINC client again. When it requests work from the scheduling server, it will report its platform as 'anonymous' and send a list of the applications you have supplied. The server will sends tasks for those applications.

I have never used the anonymous platform before. I was basing my responses on this:
https://github.com/BOINC/boinc/wiki/Anonymous-platform
Did you follow these instructions regarding the app_info.xml:

To use the anonymous platform mechanism for a particular project:
    1.  Get the project's application source code and compile it, or download an executable from a third party.
    2.  Run the BOINC client and attach to the project. This will create a 'project directory' (whose name is the project URL) in the BOINC directory. Exit the client. Put your executables in the project directory (Mac OS X users: see note below).
    3.  Create a file app_info.xml in the project directory. This file describes the applications you have compiled or downloaded. Its format is described below.
    4.  Run the BOINC client again. When it requests work from the scheduling server, it will report its platform as 'anonymous' and send a list of the applications you have supplied. The server will sends tasks for those applications.

Anonymous platform is meant for client side only, i.e. the volunteers create their custom app, follow the instructions as you pointed out to create app_config.xml file. This is what I believe Alperen is trying to do which was unsuccessful thus far.

What you are doing now is adding "Decic Field Testing" application to your currently available list of applications to run and this is done and manage on the server side, i.e. the executables and necessary files must be made available on the server side. Perhaps the section under "beta-test applications" not "beta-test projects" in this website https://github.com/BOINC/boinc/wiki/BetaTest may be of use. I've no experience in hosting a boinc project, perhaps Alperen my provide better guidance than me.

The anonymous platform is rejected because the server has no platform named "anonymous". The scheduler answers "This project doesn't support computers of type anonymous" and sets a 24 h delay.

Check:

SELECT * FROM platform WHERE name = 'anonymous';

If it returns nothing, add it:

INSERT INTO platform (create_time, name, user_friendly_name, deprecated)
VALUES (UNIX_TIMESTAMP(), 'anonymous', 'anonymous', 0);

Then restart the feeder (or bin/stop and bin/start), since the scheduler reads the platform list from shared memory.

No test app is needed after that; my client reports its own versions of the existing GetDecics app.

The anonymous platform is rejected because the server has no platform named "anonymous". The scheduler answers "This project doesn't support computers of type anonymous" and sets a 24 h delay.

Check:

SELECT * FROM platform WHERE name = 'anonymous';

If it returns nothing, add it:

INSERT INTO platform (create_time, name, user_friendly_name, deprecated)
VALUES (UNIX_TIMESTAMP(), 'anonymous', 'anonymous', 0);

Then restart the feeder (or bin/stop and bin/start), since the scheduler reads the platform list from shared memory.

No test app is needed after that; my client reports its own versions of the existing GetDecics app.

---

According to Gemini:

The reason you are seeing "This project doesn't support computers of type anonymous" is a common point of confusion when setting up a BOINC server.
Even though it uses the word "type", the scheduler is not looking for a platform named "anonymous". Adding <platform>anonymous</platform> to your server's project.xml file will not fix this, as "anonymous" is not a valid global BOINC architecture code.
The Real Cause of the Error:
When a user wants to utilize the Anonymous Platform mechanism, their client sends a request to your scheduler saying, "I have my own binaries for Application X on Platform Y".
The scheduler throws this specific error if either of the following is true on your server:
• The platform they are using doesn't exist on your server: For example, if the user's app_info.xml file lists their platform as windows_x86_64, but you haven't added windows_x86_64 to your server's project.xml and run x_add_platforms, the server rejects it.
• The application name doesn't match: If the user's app_info.xml lists an <app_name> that doesn't exactly match an entry in your server's database, the scheduler will fail to find a match and fall back to this generic error.

Note that the app name must be: "testDecics". Platform names are the BOINC standard. Can you post your app_info.xml file?

I will attempt this from one of my computers using one of your executables from the link you gave.