| | 17 | |
| | 18 | {{{ |
| | 19 | <ignore_delay_bound/> |
| | 20 | }}} |
| | 21 | By default, results are not sent to hosts too slow to complete them within delay bound. |
| | 22 | If this flag is set, this rule is not enforced. |
| | 23 | {{{ |
| | 24 | <ban_os>regexp</ban_os> |
| | 25 | }}} |
| | 26 | Any host for which os_name<tab>os_version matches the given regular expression will not be sent jobs. |
| | 27 | This is a POSIX extended regular expression. |
| | 28 | {{{ |
| | 29 | <ban_cpu>regexp</ban_cpu> |
| | 30 | }}} |
| | 31 | Any host for which p_vendor<tab>p_model matches the given regular expression will not be sent jobs. |
| | 32 | This is a POSIX extended regular expression. |
| | 33 | {{{ |
| | 34 | <workload_sim>0|1</workload_sim> |
| | 35 | }}} |
| | 36 | Do a simulation, based on current client workload, in deciding whether a job's deadline can be met. |
| | 37 | {{{ |
| | 38 | <homogeneous_redundancy>N</homogeneous_redundancy> |
| | 39 | }}} |
| | 40 | If zero (default) don't use the [HomogeneousRedundancy homogeneous redundancy] mechanism. |
| | 41 | Otherwise, specifies the granularity of host classification (1=fine, 2=coarse). |
| | 42 | (Note: you may also specify this on a per-application basis). |
| | 43 | {{{ |
| | 44 | <distinct_beta_apps>0|1</distinct_beta_apps> |
| | 45 | }}} |
| | 46 | If set, [AppFiltering user application selection] applies to [BetaTest beta test applications] as well as others. |
| | 47 | {{{ |
| | 48 | <nowork_skip> 0|1 </nowork_skip> |
| | 49 | }}} |
| | 50 | If the scheduler has no work, it replies to RPCs without doing any database access |
| | 51 | (e.g., without looking up the user or host record). |
| | 52 | This reduces DB load, but it fails to update preferences when users click on Update. |
| | 53 | Use it if your server DB is overloaded. |
| | 54 | {{{ |
| | 55 | <multiple_clients_per_host>0|1</multiple_clients_per_host> |
| | 56 | }}} |
| | 57 | Set this if some of your hosts run multiple BOINC clients simultaneously |
| | 58 | (this is the case on projects that use Condor and/or grid resources, |
| | 59 | which require each client to use only 1 CPU). |
| | 60 | If set, the scheduler will skip a check that tries to locate the host |
| | 61 | based on its IP address. |
| | 62 | |
| | 63 | === Job limits === |
| | 96 | <max_jobs_in_progress> |
| | 97 | <project> |
| | 98 | <total_limit> |
| | 99 | <jobs>N</jobs> |
| | 100 | </total_limit> |
| | 101 | [ <gpu_limit> ] |
| | 102 | <jobs>N</jobs> |
| | 103 | [ <per_proc/> ] |
| | 104 | if set, limit is per processor |
| | 105 | [ <cpu_limit> ] |
| | 106 | ... |
| | 107 | </project> |
| | 108 | <app> |
| | 109 | <app>name</app> |
| | 110 | [ <total_limit> ... ] |
| | 111 | [ <cpu_limit> ... ] |
| | 112 | [ <gpu_limit> ... ] |
| | 113 | </app> |
| | 114 | ... |
| | 115 | </max_jobs_in_progress> |
| | 116 | }}} |
| | 117 | A more adaptable way of expressing limits on the number of jobs in progress on a host. |
| | 118 | You can specify limits for specific apps, and for your projects as a whole. |
| | 119 | Within each of these, you can specify limits for CPU jobs, GPU jobs, or total. |
| | 120 | In the case of CPU and GPU jobs, you can specify whether the limit should be |
| | 121 | scaled by the number of devices present on the host. |
| | 122 | |
| | 123 | {{{ |
| 67 | | {{{ |
| 68 | | <ignore_delay_bound/> |
| 69 | | }}} |
| 70 | | By default, results are not sent to hosts too slow to complete them within delay bound. |
| 71 | | If this flag is set, this rule is not enforced. |
| 72 | | {{{ |
| 73 | | <ban_os>regexp</ban_os> |
| 74 | | }}} |
| 75 | | Any host for which os_name<tab>os_version matches the given regular expression will not be sent jobs. |
| 76 | | This is a POSIX extended regular expression. |
| 77 | | {{{ |
| 78 | | <ban_cpu>regexp</ban_cpu> |
| 79 | | }}} |
| 80 | | Any host for which p_vendor<tab>p_model matches the given regular expression will not be sent jobs. |
| 81 | | This is a POSIX extended regular expression. |
| 82 | | {{{ |
| 83 | | <workload_sim>0|1</workload_sim> |
| 84 | | }}} |
| 85 | | Do a simulation, based on current client workload, in deciding whether a job's deadline can be met. |
| 86 | | {{{ |
| 87 | | <homogeneous_redundancy>N</homogeneous_redundancy> |
| 88 | | }}} |
| 89 | | If zero (default) don't use the [HomogeneousRedundancy homogeneous redundancy] mechanism. |
| 90 | | Otherwise, specifies the granularity of host classification (1=fine, 2=coarse). |
| 91 | | {{{ |
| 92 | | <distinct_beta_apps>0|1</distinct_beta_apps> |
| 93 | | }}} |
| 94 | | If set, [AppFiltering user application selection] applies to [BetaTest beta test applications] as well as others. |
| 95 | | {{{ |
| 96 | | <nowork_skip> 0|1 </nowork_skip> |
| 97 | | }}} |
| 98 | | If the scheduler has no work, it replies to RPCs without doing any database access (e.g., without looking up the user or host record). |
| 99 | | This reduces DB load, but it fails to update preferences when users click on Update. |
| 100 | | Use it if your server DB is overloaded. |
| 101 | | {{{ |
| 102 | | <multiple_clients_per_host>0|1</multiple_clients_per_host> |
| 103 | | }}} |
| 104 | | Set this if some of your hosts run multiple BOINC clients simultaneously |
| 105 | | (this is the case on projects that use Condor and/or grid resources, |
| 106 | | which require each client to use only 1 CPU). |
| 107 | | If set, the scheduler will skip a check that tries to locate the host |
| 108 | | based on its IP address. |
| 109 | | {{{ |
| 110 | | <max_ncpus>N</max_ncpus> |
| 111 | | }}} |
| 112 | | An upper bound on NCPUS (default: 8) |
| 113 | | |
| 114 | | {{{ |
| 115 | | <ignore_dcf>0|1</ignore_dcf> |
| 116 | | }}} |
| 117 | | If true, ignore duration correction factor. |
| 118 | | Use this temporarily if you've made a major change to your workunit FLOPS estimates. |
| | 149 | |
| 167 | | * The scheduler tries to send need-reliable jobs to reliable hosts. When it does, it reduces the delay bound of the job. |
| 168 | | * When job replicas are created in response to errors or timeouts, their priority is raised relative to the job's base priority. |
| | 198 | * The scheduler tries to send need-reliable jobs to reliable hosts. |
| | 199 | When it does, it reduces the delay bound of the job. |
| | 200 | * When job replicas are created in response to errors or timeouts, |
| | 201 | their priority is raised relative to the job's base priority. |
| 224 | | If set, and a <other_results> list is present in scheduler request, resend any in-progress results not in the list. This is recommended; it may increase the efficiency of your project. For reasons that are not well understood, a BOINC client sometimes fails to receive the scheduler reply. This flag addresses that issue: it causes the SAME results to be resent by the scheduler, if the client has failed to receive them. Note: this will increase the load on your DB server; you can minimize this by creating an index: |
| | 261 | If set, and a <other_results> list is present in scheduler request, resend any in-progress results not in the list. |
| | 262 | This is recommended; it may increase the efficiency of your project. |
| | 263 | For reasons that are not well understood, a BOINC client sometimes fails to receive the scheduler reply. |
| | 264 | This flag addresses that issue: it causes the SAME results to be resent by the scheduler, |
| | 265 | if the client has failed to receive them. |
| | 266 | Note: this will increase the load on your DB server; you can minimize this by creating an index: |
| 231 | | If set, and the client is processing a result for a WU that has been canceled or is not in the DB (i.e. there's no chance of getting credit), tell the client to abort the result regardless of state. If client is processing a result for a WU that has been assimilated or is overdue (i.e. there's a chance of not getting credit) tell the client to abort the result if it hasn't started yet. Note: this will increase the load on your DB server. |
| | 273 | If set, and the client is processing a result for a WU that has been canceled or is not in the DB |
| | 274 | (i.e. there's no chance of getting credit), tell the client to abort the result regardless of state. |
| | 275 | If client is processing a result for a WU that has been assimilated or is overdue |
| | 276 | (i.e. there's a chance of not getting credit) tell the client to abort the result if it hasn't started yet. |
| | 277 | Note: this will increase the load on your DB server. |
| 239 | | When the scheduler sends work to hosts, it replaces the download URL appearing in the data and executable file descriptions with the download URL closest to the host's timezone. The project must provide a two-column file called 'download_servers' in the project root directory. This is a list of all download servers that will be inserted when work is sent to hosts. The first column is an integer listing the server's offset in seconds from UTC. The second column is the server URL in the format such as !http://einstein.phys.uwm.edu. The download servers must have identical file hierarchies and contents, and the path to file and executables must start with '/download/...' as in '!http://X/download/123/some_file_name'. |
| | 285 | When the scheduler sends work to hosts, |
| | 286 | it replaces the download URL appearing in the data and executable file descriptions |
| | 287 | with the download URL closest to the host's timezone. |
| | 288 | The project must provide a two-column file called 'download_servers' in the project root directory. |
| | 289 | This is a list of all download servers that will be inserted when work is sent to hosts. |
| | 290 | The first column is an integer listing the server's offset in seconds from UTC. |
| | 291 | The second column is the server URL in the format such as !http://einstein.phys.uwm.edu. |
| | 292 | The download servers must have identical file hierarchies and contents, |
| | 293 | and the path to file and executables must start with '/download/...' as in '!http://X/download/123/some_file_name'. |
| 243 | | When creating work, keep a record (in files called foo.md5) of the file length and md5 sum of data files and executables. This can greatly reduce the time needed to create work, if (1) these files are re-used, and (2) there are many of these files, and (3) reading the files from disk is time-consuming. |
| | 297 | When creating work, keep a record (in files called foo.md5) of the file length and md5 sum of data files and executables. |
| | 298 | This can greatly reduce the time needed to create work, if (1) these files are re-used, and (2) there are many of these files, |
| | 299 | and (3) reading the files from disk is time-consuming. |
| 378 | | Sets the default value for the `disk_max_used_pct` preference so its consistent between the scheduler and web pages. The scheduler uses it when a request for work doesn't include preferences, or the preference is set to zero. The web page scripts use it to set the initial value when displaying or editing preferences the first time, or when the user never saved them. Default is 50. |
| | 439 | Sets the default value for the `disk_max_used_pct` preference so its consistent between the scheduler and web pages. |
| | 440 | The scheduler uses it when a request for work doesn't include preferences, or the preference is set to zero. |
| | 441 | The web page scripts use it to set the initial value when displaying or editing preferences the first time, |
| | 442 | or when the user never saved them. Default is 50. |
| 382 | | Sets the default value for the `disk_min_free_gb` preference so its consistent between the scheduler and web pages. The scheduler uses it when a request for work doesn't include preferences. The web page scripts use it to set the initial value when displaying or editing preferences the first time, or when the user never saved them. Also, the scheduler uses this setting to override any smaller preference from the host, it enforces a 'minimum free disk space' to keep from filling up the drive. Recommend setting this no smaller than .001 (1MB or 1,000,000 bytes). Default is .001. |
| 383 | | |
| 384 | | |
| | 446 | Sets the default value for the `disk_min_free_gb` preference so its consistent between the scheduler and web pages. |
| | 447 | The scheduler uses it when a request for work doesn't include preferences. |
| | 448 | The web page scripts use it to set the initial value when displaying or editing preferences the first time, |
| | 449 | or when the user never saved them. |
| | 450 | Also, the scheduler uses this setting to override any smaller preference from the host, |
| | 451 | it enforces a 'minimum free disk space' to keep from filling up the drive. |
| | 452 | Recommend setting this no smaller than .001 (1MB or 1,000,000 bytes). Default is .001. |
| 398 | | The weighting given to the Whetstone benchmark in the calculation of claimed credit. Must be in [0 .. 1]. Projects whose applications are floating-point intensive should use 1; pure integer applications, 0. Choosing an appropriate value will reduce the disparity in claimed credit between hosts. The script html/ops/credit_study.php, run against the database of a running project, will suggest what value to use. |
| | 466 | The weighting given to the Whetstone benchmark in the calculation of claimed credit. |
| | 467 | Must be in [0 .. 1]. Projects whose applications are floating-point intensive should use 1; pure integer applications, 0. |
| | 468 | Choosing an appropriate value will reduce the disparity in claimed credit between hosts. |
| | 469 | The script html/ops/credit_study.php, run against the database of a running project, will suggest what value to use. |
