Posts by SteveTheCynic

1) Message boards : Questions and problems : Is there a way to get BOINC to give priority to Tasks with short "time to deadline"? (Message 107622)
Posted 29 Mar 2022 by SteveTheCynic
Post:
As an example, CDPN has a deadline of one year but only take about 10 days to run on most modern systems. It would make no sense to delay them by 350 days before running them.


OK, Fair enough. I didn't realise anything would put out deadlines *that* long. The projects I've been running (i.e. what Science United drops on me) generally have deadlines up to about ten days, with three or four hour runtimes at the longest.
2) Message boards : Questions and problems : Is there a way to get BOINC to give priority to Tasks with short "time to deadline"? (Message 107609)
Posted 28 Mar 2022 by SteveTheCynic
Post:
If BOINC were to exclusively run the tasks with the short deadline first, then when would it run the tasks with the long deadline?

Is that a trick question? The obvious answer is that it would start to pick them up as they become (progressively) the shortest deadlines.
BOINC makes calculations based on the information that the project gives to the tasks whether it can run tasks within the given deadline, and run them accordingly. And even if it cannot run all tasks on your system within the deadline, there's no man overboard as most projects have a redundancy where tasks are run by multiple computers. And tasks not run on yours will be run on another's.

I know that, but the question is why it seems to reject the idea of giving priority to running the short-deadline ones. It's pretty close to 100% consistent. Short-deadline (but still achievable) tasks sit idle while long-deadline (even taking into account the estimated time to completion) tasks run. Even on the same project. When the difference in estimated completion time is several days or even upwards of a week. Even when the short-deadline task would take two minutes to run from zero to done.

If there's some other priority (like what was done for Rosetta when they started doing Covid folding at the beginning of the pandemic), that's fine, but a way to show it on the UI would help.
3) Message boards : Questions and problems : Is there a way to get BOINC to give priority to Tasks with short "time to deadline"? (Message 107608)
Posted 28 Mar 2022 by SteveTheCynic
Post:
If the short deadline tasks are in danger of not completing then Boinc will put them into high priority mode and drop any other tasks until they are completed. Until that point is reached Boinc will run the tasks according to the project share you have assigned.

OK. That's not remotely clear from the UI, and I haven't touched the project share, which means, I presume, that it's equal everywhere.

And the observed behaviour isn't just between different projects, but between different tasks of the same project.
4) Message boards : Questions and problems : Is there a way to get BOINC to give priority to Tasks with short "time to deadline"? (Message 107587)
Posted 27 Mar 2022 by SteveTheCynic
Post:
Or at least to show me (on the BOINC Manager display) why the longer-deadline tasks are running instead of the shorter ones?

I have a couple of locally-configured projects, and Science United for the rest. I tend to see some tasks with deadlines around two days from now sitting idle ("waiting to start" or "waiting to run"), with some that are due in seven to ten days' time that are running. Even when you include the estimated remaining run-time of the tasks, it seems perverse to leave soon-to-expire tasks idle while not-soon tasks run.

Windows 11, i9-10980XE (18 HT cores), NVidia 2080Ti, 64GB system RAM.

EDIT: BOINC 7.16.20
5) Message boards : Questions and problems : Download, upload, and Notices don't work on wired LAN; work on wireless guest LAN (Message 107585)
Posted 27 Mar 2022 by SteveTheCynic
Post:
As robsmith pointed out in the last post it's a wired -vs- wireless difference in connectivity problem in your firewall settings.

I would suggest you contact your firewall provider for help in setting it up and getting it working properly as this does not appear to be a BOINC issue.

Pretty much this. I work as a developer for a *different* firewall company (which one it is isn't relevant here), and it's possible to:
* Deactivate the TLS proxy altogether. (By default, it's not active anyway.)
* Add exceptions based on the server certificate's alt-names to not decrypt traffic (which then lets the "true" server certificate through).

OP (and anyone else with this problem) should investigate either or both of these possibilities.
6) Message boards : Questions and problems : How to tell the BOINC Client to not accept jobs above a certain number of CPUs? (Message 106621)
Posted 31 Dec 2021 by SteveTheCynic
Post:
If the application is a MT (multi-thread) one as likely by what you describe, BOINC has a native configuration setting in the app_config file to limit the number of threads a MT application is allowed to use.
https://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration

Specifically this part referencing nthreads. Just reduce the number from 32 to 4 or whatever how many you want the app to use.

[<app_config>
[<app_version>
<app_name>Application_Name</app_name>
[<plan_class>mt</plan_class>]
[<avg_ncpus>x</avg_ncpus>]
[<ngpus>x</ngpus>]
[<cmdline>--nthreads 7</cmdline>]
</app_version>]
...
[<project_max_concurrent>N</project_max_concurrent>]
[<report_results_immediately/>]
</app_config>

OK, that looks interesting. However, it doesn't seem to work for the existing jobs. If I look at their properties:

Application                camb_boinc2docker 2.05 (vbox64_mt)
Name                       camb_boinc2docker_1265887_1640858474.018410
State                      Ready to start
Received                   30/12/2021 11:18:28
Report deadline 06/01/2022 11:18:28
Resources                  32 CPUs
Estimated computation size 18,000 GFLOPs
Executable                 vboxwrapper_26200_windows_x86_64.exe

So, a few questions:

1. Which of "camb_boinc2docker 2.05 (vbox64_mt)" and "camb_boinc2docker_1265887_1640858474.018410" goes in the <app_name> tag? (the numbers after "camb_boinc2docker" in the second type are different on each job).

2. Or do I have to trash the existing jobs and start again?

3. Or should I just give up and leave Cosmology permanently excluded? (I'm leaning toward this, since these jobs never actually compute anything - they are *all* aborted for taking too long after a bit less than nine minutes.)

4. Or dump Science United?

EDIT: I don't really want to dump Science United, because I like to see the unusual things it proposes, but I want it to propose projects whose calculations actually *use* my computer...
7) Message boards : Questions and problems : How to tell the BOINC Client to not accept jobs above a certain number of CPUs? (Message 106610)
Posted 30 Dec 2021 by SteveTheCynic
Post:
OK, thanks. That's more or less what I thought. That said, is there a way to restrict projects so I can limit the maximum value of N in an "N CPUs" work unit / task?

Or is this something that each project does differently, if at all?

Thanks again for confirming my suspicions.
8) Message boards : Questions and problems : How to tell the BOINC Client to not accept jobs above a certain number of CPUs? (Message 106608)
Posted 30 Dec 2021 by SteveTheCynic
Post:
Cosmology@Home is at it again, sending me 32-CPU jobs. They *work*, kinda, except that they don't actually consume any CPU time, but they do block 32 out of 36 hyperthreads (i9 10980XE, 18 HT cores), which means the machine is under-used.

Is there a way to tell the project to send me jobs for at most 8 CPUs? If so, does it mean I have to exclude it *again*(1) on Science United and add it manually? I don't mind helping the project, but my PC isn't there for their exclusive use, especially if they are going to reserve it but not actually use it.

(1) Some time back, I excluded it based on this misbehaviour, and I thought I'd give it a chance. Looks like I was wrong. Or maybe they don't get information from Science United about who has excluded their project.



Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.