[Debian Wiki] Update of "BOINC/ServerGuide" by SteffenMoeller

[Debian Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "BOINC/ServerGuide" page has been changed by SteffenMoeller:
http://wiki.debian.org/BOINC/ServerGuide?action=diff&rev1=94&rev2=95

Comment:
added section on validator

  The project should now be ready to run a couple of work units. Please use any Linux BOINC client. The Debian [[DebPkg:boinc-client]] package will do. It needs to be Linux since our application was yet only prepared for this OS. The project URL is $hosturl/$fileprojectname.
  
  
- == Inspection ==
+ == Treatment of results ==
+ 
+ === Inspection of internal representation ===
  
  Once the user was created, the respective entry in the database will look like {{{
  mysql> select id,create_time,email_addr,name,authenticator,country,postal_code,url,donated from user;
@@ -315, +317 @@

  ---+-------------+------------+-------+------+------+--------+----------+---------------+-----
   1 |  1310217514 |          1 |      1|    1 |    1 | test_0 | 19.94525 |           612 |   11
  }}}
+ 
+ the workunitid points to the compute challenge/job. When the job is executed multiple times, there
+ will be multiple results for the same work unit {{{
+ mysql> select id,create_time,appid,name,need_validate from workunit;
+  id | create_time | appid | name | need_validate 
+ ----+-------------+-------+------+---------------
+   1 |  1310213354 |    11 | test |             1 
+ }}}
+ 
+ The "need_validate" on 1 means that this result is not yet trusted to be correct.
+ 
+ === Validation  ===
+ 
+ The validation is nicely described at http://boinc.berkeley.edu/trac/wiki/ValidationIntro . It is refering to a tool that decides if a result can be trusted or not. Typically this is by replication: two independent runs by different individuals should give the same results. The difficulty is not the false positive result, you just recompute. It is the false negatives - a good result falsely uploaded, which is of concern.
+ 
+ Here we aim not at wild internet project but at projects for local groups. We shall do without verification. If this is acceptable will depend on your project. You take the following security measures:
+  * a single false negative result will not be considered too dramatic because of some redundancy in the analysis, say by an identification of a cluster of results
+  * you invite colleagues, students and their families to contribute, so the scientific value becomes evident to everyone and one feels connected to the research
+  * to cheat shall be not too difficult, hence not technically interesting
+  * you don't give credit for the results
+  * you compare individual results with your own calculations
+ 
+ The boinc-server-maker package provides the [[http://boinc.berkeley.edu/trac/wiki/ValidationSimple|example validatators]] in /usr/lib/boinc-server/bin/sample_binary_validator . We suggest to gain some experience with this one, basically asking it not to validate at all except for completeness of the upload. This reduces the complexity for now and your very first project is likely not to profit too much from your investment at this corner.
+ 
+ For the integration of the validator with the project, you do not call the thing directly. Well you could, actually, just make sure you are running as the right user, otherwise you cannot read the files: {{{
+ /usr/lib/boinc-server/bin/sample_bitwise_validator -app upper_case --one_pass -d 4 
+ }}}
+ The workunit needed to be validated then is assigned the credits and so are the users. Since one is not interested in executing such manually too often, one could either create a UNIX-typical cron file, or the daemon facility that BOINC provides. It may look like {{{
+     <daemon>
+       <cmd>
+          sample_bitwise_validator -app upper_case --sleep_interval 600 -d 3
+       </cmd>
+     </daemon>
+ }}}
+ Every 10 minutes should be sufficient.
+ 
+ === Access on result files ===
+ 
+ The previously described output template describes what files are expected to be created. Those are shipped back and can then be prepared for subsequent scrutiny. This is explained neatly on http://boinc.berkeley.edu/trac/wiki/AssimilateIntro . For projects that have only results that are successfully validated and that have only one file per workunit, the action to be performed is basically "none". Well, One moves the right file of the many (for complicated projects) into some result area that is then archived. For our purpose, the assimilator could just be "mv", the file mover. But there is also some special communciation with the server, so 
+ 
  Result files are at {{{
- $ find upload/
+ $ find $installroot/$fileprojectname/upload/
  upload/
  upload/ba
  upload/ba/test_0_0