Changes between Version 88 and Version 89 of ProjectOptions


Ignore:
Timestamp:
Jun 1, 2009, 11:15:14 AM (12 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProjectOptions

    v88 v89  
    2626This is weaker than `one_result_per_user_per_wu`;
    2727it is useful if you're using homogeneous redundancy and most of the hosts of a particular class belong to a single user.
     28
     29{{{
     30<min_sendwork_interval> N </min_sendwork_interval>
     31}}}
     32Minimum number of seconds between sending jobs to a given host.
     33You can use this to limit the impact of faulty hosts.
     34
     35{{{
     36<max_wus_in_progress> N </max_wus_in_progress>
     37[<max_wus_in_progress_gpu> M </max_wus_in_progress_gpu>
     38}}}
     39Limit the number of jobs in progress on a given host.
     40Starting with 6.8, the BOINC client report the resources used by in-progress jobs;
     41in this case, the max CPU jobs in progress is '''N*NCPUS'''
     42and the max GPU jobs in progress is '''M*NGPUs'''.
     43Otherwise, the overall maximum is '''N*NCPUS + M*NGPUS)'''.
     44
     45{{{
     46<gpu_multiplier> GM </gpu_multiplier>
     47}}}
     48If your project uses GPUs, set this to roughly the ratio
     49of GPU speed to CPU speed.
     50Used in the calculation of job limits (see next 2 items).
    2851{{{
    2952<max_wus_to_send> N </max_wus_to_send>
    3053}}}
    31 Maximum results sent per scheduler RPC.
    32 Helps prevent hosts from getting too many jobs and trashing them.
    33 But you should set this large enough so that a host which is only connected to the network
    34 at intervals has enough work to keep it occupied between connections.
    35 {{{
    36 <max_wus_in_progress> A </max_wus_in_progress>
    37 [ <max_wus_in_progress_cpu> B </max_wus_in_progress_cpu> ]
    38 [ <max_wus_in_progress_gpu> C </max_wus_in_progress_gpu> ]
    39 }}}
    40 The maximum jobs in progress on a given host is '''min(A, (B*#CPUs + C*#GPUS)'''.
    41 Starting with 6.8, the BOINC client report the resources used by in-progress jobs;
    42 in this case, the max CPU jobs in progress is '''B*#CPUs''',
    43 the max GPU jobs in progress is '''C*#GPUs''',
    44 and the max total jobs in progress is A.
    45 {{{
    46 <min_sendwork_interval> N </min_sendwork_interval>
    47 }}}
    48 Minimum number of seconds to wait after sending results to a given host, before new results are sent to the same host. Helps prevent hosts with download or application problems from trashing lots of results by returning lots of error results. But don't set it to be so long that a host goes idle after completing its work, before getting new work.
     54Maximum jobs returned per scheduler RPC is '''N*(NCPUS + GM*NGPUS)'''.
     55You can use this to limit the impact of faulty hosts.
     56
    4957{{{
    5058<daily_result_quota> N </daily_result_quota>
    5159}}}
    52 Each host has a field max_results_day in the interval [1 .. daily_result_quota];
     60Each host has a field MRD in the interval [1 .. daily_result_quota];
    5361it's initially daily_result_quota, and is adjusted as the host sends good or bad results.
    54 The maximum number of jobs sent to a given host in a 24-hour period is MRD * NCPUs.
    55 
    56 Set daily_result_quota large enough that a host can download enough work
    57 to keep it busy if disconnected from the net for a few days.
    58 {{{
    59 <cuda_multiplier>N</cuda_multiplier>
    60 }}}
    61 See the above.
    62 If a host has M CUDA devices, use M*N instead of NCPUS.
    63 Set this to the speed ratio of an average CUDA device to an average CPU, i.e. about 10 or 20.
    64 
     62The maximum number of jobs sent to a given host in a 24-hour period is '''MRD*(NCPUS + GM*NGPUS)'''.
     63You can use this to limit the impact of faulty hosts.
    6564{{{
    6665<ignore_delay_bound/>
    6766}}}
    68 By default, results are not sent to hosts too slow to complete them within delay bound. If this flag is set, this rule is not enforced.
     67By default, results are not sent to hosts too slow to complete them within delay bound.
     68If this flag is set, this rule is not enforced.
    6969{{{
    7070<ban_os>regexp</ban_os>
    7171}}}
    72 Any host for which os_name<tab>os_version matches the given regular expression will not be sent jobs. This is a POSIX extended regular expression.
     72Any host for which os_name<tab>os_version matches the given regular expression will not be sent jobs.
     73This is a POSIX extended regular expression.
    7374{{{
    7475<ban_cpu>regexp</ban_cpu>
    7576}}}
    76 Any host for which p_vendor<tab>p_model matches the given regular expression will not be sent jobs. This is a POSIX extended regular expression.
     77Any host for which p_vendor<tab>p_model matches the given regular expression will not be sent jobs.
     78This is a POSIX extended regular expression.
    7779{{{
    7880<workload_sim>0|1</workload_sim>
     
    9193<nowork_skip> 0|1 </nowork_skip>
    9294}}}
    93 If the scheduling server has no work, it replies to RPCs without doing any database access (e.g., without looking up the user or host record). This reduces DB load, but it fails to update preferences when users click on Update. Use it if your server DB is overloaded.
     95If the scheduling server has no work, it replies to RPCs without doing any database access (e.g., without looking up the user or host record). This reduces DB load, but it fails to update preferences when users click on Update.
     96Use it if your server DB is overloaded.
    9497{{{
    9598<multiple_clients_per_host>0|1</multiple_clients_per_host>