Rooba
/
boinc
mirror of https://github.com/BOINC/boinc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Sporadic Applications (markdown)

David Anderson 2023-10-02 19:31:50 -07:00
parent aae2ef17bd
commit da225d408b
1 changed files with 21 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Sporadic-Applications.md

@ -2,22 +2,26 @@ BOINC was originally designed as a batch processing system:
you submit jobs, they run (independently of each other)
and eventually finish.
But some potential uses of volunteer computing don't fit this model.
They may require that their apps run simultaneously on different computers,
They may require that apps run simultaneously on different computers,
and perhaps that they communicate directly with each other.
Examples include MPI-type parallel computing and distributed machine learning.
BOINC's 'sporadic application' mechanism is designed to support these types of systems,
and to allow them to coexist with batch processing.
The jobs of a sporadic app run (i.e. are present in memory)
all the time, like non-CPU-intensive jobs,
but compute only some of the time.
Like regular apps, a sporadic app can have multiple app versions.
Each of these app versions has a plan class,
Each of these has a plan class,
which determines the processor usage (CPUs and GPUs) of its jobs.
A project's BOINC scheduler can send multiple jobs for a given sporadic app,
using the same or different app versions.
A BOINC project can provide any combination of
regular, sporadic, and non-CPU-intensive apps.
A client can be connected to multiple projects with sporadic apps.
Like regular jobs, a sporadic job can compute only when
* computing (and GPU computing if relevant) is enabled by user preferences
* there are sufficient processing resources and RAM
@ -122,5 +126,18 @@ enum SPORADIC_AC_STATE {
extern void boinc_sporadic_set_ac_state(SPORADIC_AC_STATE);
extern SPORADIC_CA_STATE boinc_sporadic_get_ca_state();
```
## Prioritization of sporadic apps
In the initial implementation of sporadic apps (client 7.26),
sporadic apps have strict priority over regular apps.
Thus if a sporadic app does lots of computing
it can starve regular app.
If multiple sporadic apps compete for a resource (say, a GPU)
the prioritization is fixed; one of them can starve the others.
In a later version, sporadic apps will be scheduled using the same
scheme that is used for regular apps,
in which resource share determines prioritization
and starvation is eliminated.