Changes between Version 86 and Version 87 of ProjectOptions


Ignore:
Timestamp:
Jun 1, 2009, 9:56:49 AM (15 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProjectOptions

    v86 v87  
    1717<one_result_per_user_per_wu/>
    1818}}}
    19 If set, send at most one result of a given workunit to a given user. This is useful for checking accuracy/validity of results. It ensures that the results for a given workunit are generated by different users. If you have a validator that compares different results for a given workunits to ensure that they are equivalent, you should probably enable this. Otherwise you may end up validating results from a given user with results from the same user.
     19If set, send at most one instance of a given job to a given user.
     20This increases the effectiveness of replication-based validation
     21by making it more difficult for hackers to get all the instances of a given job.
    2022{{{
    2123<one_result_per_host_per_wu/>
    2224}}}
    23 If present, send at most one result of a given workunit to a given host. This is weaker than `one_result_per_user_per_wu`; it is useful if you're using homogeneous redundancy and most of the hosts of a particular class belong to a single user.
     25If present, send at most one result of a given workunit to a given host.
     26This is weaker than `one_result_per_user_per_wu`;
     27it is useful if you're using homogeneous redundancy and most of the hosts of a particular class belong to a single user.
    2428{{{
    2529<max_wus_to_send> N </max_wus_to_send>
    2630}}}
    27 Maximum results sent per scheduler RPC. Helps prevent hosts with trouble from getting too many results and trashing them. But you should set this large enough so that a host which is only connected to the net at intervals has enough work to keep it occupied in between connections.
    28 {{{
    29 <max_wus_in_progress> N </max_wus_in_progress>
    30 }}}
    31 The maximum results in progress is N times NCPUS (NCPUS is typically the number of CPUs on the host; see below). Setting this to something (like 2 for instance) will limit the number of results a given host can simultaneously have registered as 'in progress'.
     31Maximum results sent per scheduler RPC.
     32Helps prevent hosts from getting too many jobs and trashing them.
     33But you should set this large enough so that a host which is only connected to the network
     34at 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 rsc="cpu"> B </max_wus_in_progress> ]
     38[ <max_wus_in_progress rsc="gpu"> C </max_wus_in_progress> ]
     39}}}
     40The maximum jobs in progress on a given host is min (A, (B*#CPUs + C*#GPUS).
     41Starting with 6.8, the BOINC client report the resources used by in-progress jobs;
     42in this case, the max CPU jobs in progress is B*#CPUs,
     43the max GPU jobs in progress is C*#GPUs,
     44and the max total jobs in progress is A.
    3245{{{
    3346<min_sendwork_interval> N </min_sendwork_interval>