mirror of https://github.com/BOINC/boinc.git
76 lines
2.6 KiB
HTML
76 lines
2.6 KiB
HTML
|
<h2>Compute model: results</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
A <b>result</b> describes an instance of a computation,
|
||
|
|
either to be performed, in progress, or completed.
|
||
|
|
Results are stored in the <b>result</b> table of the BOINC DB.
|
||
|
|
The attributes of a result include:
|
||
|
|
<ul>
|
||
|
|
<li> The name of the result (unique across all results in the project).
|
||
|
|
<li> The name of the associated workunit.
|
||
|
|
<li> An XML document listing the names of its output files; see below.
|
||
|
|
<li> An XML document giving the sizes and checksums of its output files
|
||
|
|
(this is filled in after the result is completed).
|
||
|
|
<li> The stderr output of the result.
|
||
|
|
<li> The host that computed the result.
|
||
|
|
<li> The times when the result was dispatched and received.
|
||
|
|
<li> The exit status of the application.
|
||
|
|
<li> The reported CPU time.
|
||
|
|
<li> Its <b>state</b>. Values include:
|
||
|
|
<ul>
|
||
|
|
<li> Inactive (not ready to dispatch)
|
||
|
|
<li> Unsent (ready to dispatch, but not dispatched)
|
||
|
|
<li> In progress (dispatched, not done)
|
||
|
|
<li> Done successfully
|
||
|
|
<li> Timed out
|
||
|
|
<li> Done with error
|
||
|
|
</ul>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
The XML document listing the output files has the form:
|
||
|
|
<pre>
|
||
|
|
<file_info>...</file_info>
|
||
|
|
[ ... ]
|
||
|
|
<result>
|
||
|
|
<name>foobar</name>
|
||
|
|
<wu_name>blah</wu_name>
|
||
|
|
<file_ref>...</file_ref>
|
||
|
|
[ ... ]
|
||
|
|
</result>
|
||
|
|
</pre>
|
||
|
|
The components are:
|
||
|
|
<ul>
|
||
|
|
<li> The <b><name></b> element is the result name.
|
||
|
|
<li> The <b><wu_name></b> element is the workunit name.
|
||
|
|
<li> Each <b><file_ref></b> element is an association
|
||
|
|
to an output file, described by a corresponding
|
||
|
|
<b><file_info></b> element.
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The XML document describing the sizes and checksums
|
||
|
|
of the output files is just a list of
|
||
|
|
<b><file_info></b> elements, with the
|
||
|
|
<b>nbytes</b> and <b>md5_cksum</b> fields present.
|
||
|
|
The project back end must parse this field to
|
||
|
|
find the locations and checksums of output files.
|
||
|
|
<p>
|
||
|
|
Several results may be associated with a single workunit.
|
||
|
|
Results may be generated in either of two ways
|
||
|
|
(selected as part of the application):
|
||
|
|
<ul>
|
||
|
|
<li> <b>Advance generation</b> of results.
|
||
|
|
One or more result records are stored in the database
|
||
|
|
when the workunit is produced.
|
||
|
|
The scheduling server dispatches each result to a single participant host.
|
||
|
|
When all result records have been dispatched,
|
||
|
|
participants hosts are "turned away".
|
||
|
|
<li> <b>On-demand generation</b> of results.
|
||
|
|
The application specifies a "result template",
|
||
|
|
which has place-holder tokens for the output filenames.
|
||
|
|
The scheduling server, in response to a host request,
|
||
|
|
generates a new result record and sends the result template.
|
||
|
|
The host generates unique output filenames,
|
||
|
|
and returns them along when it the computation is done.
|
||
|
|
</ul>
|