int assimilate_handler(
WORKUNIT& wu, vector<RESULT>& results, RESULT& canononical_result
);
+
+This is called when either
++It's possible that both conditions might hold. +
+If assimilate_handler() returns zero, +the workunit record will be marked as assimilated. +If assimilate_handler() returns nonzero, +the assimilator will print an error message and exit. +Typically you should do this in any error situation. +
+You can use BOINC's +back-end utility functions +to get file pathnames and open files. + "; page_tail(); ?> diff --git a/doc/backend_util.php b/doc/backend_util.php new file mode 100644 index 0000000000..51a7951efa --- /dev/null +++ b/doc/backend_util.php @@ -0,0 +1,79 @@ + + +
+int get_output_file_path(RESULT const&, std::string&); ++Returns the path of a result's output file +(parses result.xml_doc_out and computes the file's position in the + hierarchical directory structure). + +
+Note: this function doesn't handle multiple output files +(if there are multiple files, it returns the path of the first one). +If your application has multiple output files, see below. +
+int try_fopen(char* path, FILE*& f, char* mode); ++Open a file, distinguishing between recoverable and nonrecoverable errors. +Returns zero on success. +Returns ERR_FOPEN if the directory is present but not the file +(this is considered a nonrecoverable error). +Returns ERR_OPENDIR if the directory is not there +(this is generally a recoverable error, like NFS mount failure). +
+double median_mean_credit(vector+Given a vector of N correct results, computes a canonical credit as follows: +const& results); +
+The database field 'result.xml_doc_out' +describes a result's output files. +It has the form +
+",htmlspecialchars("
+...
+[ ... ]
+
+ foobar
+ blah
+ blah
+ ...
+ [ ... ]
+
+"),"
+
+The components are:
++The XML document describing the sizes and checksums of the output +files is a list of <file_info> elements, +with the nbytes and md5_cksum fields present. +The project back end +must parse this field to find the locations and checksums of output files. +"; +page_tail(); +?> diff --git a/doc/benchmark.php b/doc/benchmark.php new file mode 100644 index 0000000000..8c1dfebd41 --- /dev/null +++ b/doc/benchmark.php @@ -0,0 +1,80 @@ +How benchmarks are calculated + +
+'Whetstone' is the name of the benchmark that is reported on your +[Show computers] web page as 'Measured floating point speed'. +Dhrystone is the name of the benchmark used for 'Measured integer speed'. +Floats can have fractional parts (like 1.48283 or 3.141592); +integers are whole numbers like 1, 2, 938283 or 2004. + +Whetstone does 8 different groups of tests (repeatedly of course), +times how long they took to finish, and produces a number, +[ops performed]/[time]. +These tests all use floating point math operations of the CPUs being tested. +Some of them are simple math (addition, multiplication, division) +while others compute trigonometric and exponential functions +(sine, cosine, tangent, exponent). + + +Dhrystone checks repeated integer operations +and several operating system file handling operations. + +
+Neither of the tests really checks how well/fast a system can access memory, +and SETI@home (for example) accesses memory a lot. + +
+Here is an example of memory introducing a delay: +A Pentium 4 CPU of any speed can calculate the sine of an angle in +approximately 170 ticks of its internal clock. +It could have performed 170 regular integer additions in this time. + +
+But if it wanted to do an integer addition on a number somewhere out in memory +(say it was working on a table of numbers), the +CPU might have to wait as much as 260 ticks +for this memory integer to be delivered to the CPU. +So a badly timed integer+memory +operation would take far longer than a sine calculation. + +
+This is where Celeron CPUs can really slow down. +Pentium has many features to predict when the CPU might be getting memory, +and begins getting it long before the CPU actually calculates with it. +Thus there is much less delay for most memory operations. + +
+SETI@home uses almost all single-precision floating point math, +while Whetstone is all double-precision math. +On Intel x86 processors +the speed difference in calculating single vs. double isn't very large. + +
+SETI@home uses mostly add, sub, multiply and divide. +About 20% of its time is spent in trigonometry. +Almost all the time in Whetstone is used for trigonometry. + +
+Memory access speed and trigonometry are the two major reasons that
+the benchmark results and SETI@home processing speed don't match
+up on many systems.
+
+
+Thanks to Ben Herndon for this writeup
+";
+page_tail();
+?>
diff --git a/doc/create_project.php b/doc/create_project.php
index 073a8f123e..0a60f97a06 100644
--- a/doc/create_project.php
+++ b/doc/create_project.php
@@ -101,6 +101,7 @@ How to generate tasks and handle the results.
+In some cases you may not want files to be deleted. +There are two ways to accomplish this: +
The BOINC storage model is based on files. -The inputs and outputs of applications, -and the application executables, are files. +Examples of files: +
-The BOINC core client transfers files to and from data servers -operated by the project, using HTTP. +The BOINC core client transfers files to and from project-operated +data servers using HTTP.
A file is described by an XML element of the form ".html_text(" @@ -76,16 +79,16 @@ list_item("signature_required", ); list_item("no_delete", "If present for an input (workunit) file, - indicates that the file should NOT be removed from the download/ - directory when the workunit is completed. You should use this - if a particular input file or files are used by more than one - workunit, or will be used by future, unqueued workunits." + indicates that the file should NOT be removed from the data server's + download directory when the workunit is completed. + Use this if a particular input file or files are used by more than one + workunit, or will be used by future workunits." ); list_item("no_delete", "If present for an output (result) file, - indicates that the file should NOT be removed from the upload/ + indicates that the file should NOT be removed from the data server's upload directory when the corresponding workunit is completed. - Use with caution - this may cause your upload/ directory to overflow." + Use with caution - this may cause your upload directory to overflow." ); list_item("report_on_rpc", "Include a description of this file in scheduler RPC requests, @@ -94,12 +97,11 @@ list_item("report_on_rpc", ); list_end(); echo " -These attributes allow the specification of various types of files: for -example, input or output files that are retained for use as input to -later computations.
Once a file is created (on a data server or a participant host) it -is immutable. +is immutable. +This means that all replicas of that file are assumed to be identical. +
Files may be associated with workunits, @@ -123,5 +125,29 @@ list_item("main_program", "Used for files associated with application versions. It indicates that this file is the application's main program."); list_end(); + +echo " +
+BOINC's default behavior is to delete files around +when they aren't needed any more. +Specifically: +
+Note: use BOINC's +back-end utility functions +to get file pathnames +and to distinguish recoverable and nonrecoverable file-open errors.
-Neither function should delete files. +Neither function should delete files or access the BOINC database.
A more detailed description is here.
@@ -90,46 +94,7 @@ and regards results as equivalent only if they agree byte for byte. regards any two results as equivalent if their CPU time exceeds a given minimum. -
-validate_util.C contains support functions for both of the above. -
-The database field 'result.xml_doc_out' -describes a result's output files. -It has the form -
-",htmlspecialchars("
-...
-[ ... ]
-
- foobar
- blah
- blah
- ...
- [ ... ]
-
-"),"
-
-The components are:
-
-The XML document describing the sizes and checksums of the output
-files is a list of <file_info> elements,
-with the nbytes and md5_cksum fields present.
-The project back end
-must parse this field to find the locations and checksums of output files.
";
page_tail();
?>
diff --git a/sched/assimilate_handler.h b/sched/assimilate_handler.h
index 27f36d2543..910bc3be38 100644
--- a/sched/assimilate_handler.h
+++ b/sched/assimilate_handler.h
@@ -1,4 +1,4 @@
#include