Changes between Version 1 and Version 2 of ProjectOptions

Timestamp:

Apr 19, 2007, 2:13:45 PM (17 years ago)

Author:

davea

Comment:

--

ProjectOptions

@@ +1 @@
+[[PageOutline]]
+
 = Project options =
 
@@ -74 +76 @@
     * This result will be executed whenever computation is enabled (bypassing the normal scheduling mechanism). 
 
-This is intended for applications that use little CPU time, e.g. that do network or host measurements.
+This is intended for [http://boinc.berkeley.edu/non_cpu_intensive.php applications that use little CPU time], e.g. that do network or host measurements.
 
 == Server logging ==
@@ -85 +87 @@
 
 == Credit ==
-(See also the command-line options of the validator).
+(See also the command-line options of the [http://boinc.berkeley.edu/validate.php validator]).
 {{{
 [ <fp_benchmark_weight> X </fp_benchmark_weight> ]
@@ -114 +116 @@
  one_result_per_user_per_wu::   If present, 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.
  max_wus_to_send::      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.
-min_sendwork_interval   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.
+ min_sendwork_interval::        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.
  daily_result_quota::   Maximum number of results (per CPU) sent to a given host in a 24-hour period. Helps prevent hosts with download or application problems from returning lots of error results. Be sure to set it large enough that a host does not go idle in a 24-hour period, and can download enough work to keep it busy if disconnected from the net for a few days. The maximum number of CPUS is bounded at four.
  ignore_delay_bound::   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.
-dont_generate_upload_certificates       Don't put upload certificates in results. This makes result generation a lot faster, since no encryption is done, but you lose protection against DoS attacks on your upload servers.
- locality_scheduling::  When possible, send work that uses the same files that the host already has. This is intended for projects which have large data files, where many different workunits use the same data file. In this case, to reduce download demands on the server, it may be advantageous to retain the data files on the hosts, and send them work for the files that they already have. See Locality Scheduling.
- locality_scheduling_wait_period::      This element only has an effect when used in conjunction with the previous locality scheduling element. It tells the scheduler to use 'trigger files' to inform the project that more work is needed for specific files. The period is the number of seconds which the scheduler will wait to see if the project can create additional work. Together with project-specific daemons or scripts this can be used for 'just-in-time' workunit creation. See Locality Scheduling.
+ dont_generate_upload_certificates::    Don't put upload certificates in results. This makes result generation a lot faster, since no encryption is done, but you lose protection against DoS attacks on your upload servers.
+ locality_scheduling::  When possible, send work that uses the same files that the host already has. This is intended for projects which have large data files, where many different workunits use the same data file. In this case, to reduce download demands on the server, it may be advantageous to retain the data files on the hosts, and send them work for the files that they already have. See [http://boinc.berkeley.edu/sched_locality.php Locality Scheduling].
+ locality_scheduling_wait_period::      This element only has an effect when used in conjunction with the previous locality scheduling element. It tells the scheduler to use 'trigger files' to inform the project that more work is needed for specific files. The period is the number of seconds which the scheduler will wait to see if the project can create additional work. Together with project-specific daemons or scripts this can be used for 'just-in-time' workunit creation. See [http://boinc.berkeley.edu/sched_locality.php Locality Scheduling].
  min_core_client_version::      If the scheduler gets a request from a client with a version number less than this, it returns an error message and doesn't do any other processing.
  choose_download_url_by_timezone::      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'.
-c ache_md5_info::       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.
+ cache_md5_info::       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.
  nowork_skip::  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.
  resend_lost_results::  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.