From c7e0152d27b96e05c4cb50b64b3a6cf987a5f582 Mon Sep 17 00:00:00 2001 From: Michael Gary Date: Mon, 15 Jul 2002 20:11:48 +0000 Subject: [PATCH] Added documentation svn path=/trunk/boinc/; revision=198 --- doc/api.html | 43 ++++++++++++++++++++++++++++++++++++++++++- doc/client_debug.html | 8 +++++++- doc/flow.html | 7 ++++--- doc/index.html | 2 +- doc/protocol.html | 12 ++++++++++++ doc/sched_debug.html | 4 ++++ doc/sched_policy.html | 15 ++++++++++++++- doc/test.html | 4 +++- 8 files changed, 87 insertions(+), 8 deletions(-) diff --git a/doc/api.html b/doc/api.html index 675699ff94..da909719c4 100644 --- a/doc/api.html +++ b/doc/api.html @@ -90,6 +90,47 @@ refresh period passed via boinc_init in APP_IN.

  • +The APP_IN Structure +
    +Members: + +
    +The APP_IN structure is passed via boinc_init() on initialization. +The app_preferences string contains any user preferences. The graphics structure +contains information about the OpenGL graphics settings. The api will initialize +timers such that the period of time_to_checkpoint() is checkpoint_period. The poll_period states how often the core client will poll the application for state information. The cpu_time member contains the number of seconds previously spent working on the current work unit. +

    +

    • +
  • +The APP_OUT Structure +
    +Members: + +
    +The APP_OUT structure is passed via checkpoint_completed() and app_completed(). The only member expected to be filled in by the application is percent_done. THe other members will be filled in by the api. The cpu_time_at_checkpoint contains the cpu time elapsed in this instance of the application, which can be combined with the cpu_time from the APP_IN structure for total cpu time spent on this work unit. +

    +

    • +
  • The MFILE Class
    Functions: @@ -170,4 +211,4 @@ When the application has completed it should call app_completed(), then the core client that the application has completed, and closing OpenGL windows.

    • - \ No newline at end of file + diff --git a/doc/client_debug.html b/doc/client_debug.html index 7b959595f9..b6eab994e8 100644 --- a/doc/client_debug.html +++ b/doc/client_debug.html @@ -5,7 +5,13 @@ The core client writes error messages to stderr. This mechanism is reserved for serious problems, i.e. those that reflect bugs in the core client program -or conditions that require user intervention. +or conditions that require user intervention. Specifically, +The client verifies that arguments to functions have valid +values, and will print a message to stderr on an invalid argument. +These error messages are formatted as error: CLASS_NAME.function: +error_statement argument. Common errors of this type include +unexpected NULL pointer arguments and negative lengths. Error numbers are +defined in lib/error_numbers.h.

    In addition, the core client can write a variety of "logging" diff --git a/doc/flow.html b/doc/flow.html index 69f37d8f01..c9f57b5624 100644 --- a/doc/flow.html +++ b/doc/flow.html @@ -11,11 +11,12 @@ the high-water mark and the low-water mark

    Normally the work remaining is between the high- and low-water marks. -Then the work remaining reaches the low-water mark, +When the work remaining reaches the low-water mark, the core client contacts one or more scheduling servers, and attempts to get enough work to exceed the high-water mark. The -scheduling server sends a minimum of one hour of work and a maximum of -four weeks of work. +scheduling server sends a maximum of four weeks of work. If a work unit is +not feasible for a host because it consumes too many system resources, +the scheduling server will not send that work unit.

    The amount of work (measured in FP/int ops) sent diff --git a/doc/index.html b/doc/index.html index e8517013ca..6d0feef40d 100644 --- a/doc/index.html +++ b/doc/index.html @@ -53,7 +53,7 @@

  • Scheduling server: policy
  • Scheduling server: implementation -
  • Scheduling server: debugging +
  • Scheduling server: debugging
  • Host measurements diff --git a/doc/protocol.html b/doc/protocol.html index 7e21dd1120..ffaae5204d 100644 --- a/doc/protocol.html +++ b/doc/protocol.html @@ -112,6 +112,18 @@ Reply elements include 
     <request_delay>10</request_delay>
 <message priority="low">no work available</message>
+<code_sign_key>
+    1024
+    ec8b7f60fa494ce65d70afa98f91f2ab08fb5fac3931a27524e0eb954d587846
+    29e94ce79d61f4d4bc4f9660578a06e941ca271646f11ef4d2be67f4a155e0a9
+    9908b6c814d08f0f59e9dc85afcc9d65f89a33d329d963e3fd359351ee25ca7f
+    71c3bd49a88ae609152559984b3fd7cdc4937d416a43c3357a59e7ed6cf3d30d
+    0000000000000000000000000000000000000000000000000000000000000000
+    0000000000000000000000000000000000000000000000000000000000000000
+    0000000000000000000000000000000000000000000000000000000000000000
+    0000000000000000000000000000000000000000000000000000000000010001
+    .
+</code_sign_key>
 <prefs_mod_time>123123</prefs_mod_time>
 <preferences>
     <low_water_days>1.2</low_water_days>
diff --git a/doc/sched_debug.html b/doc/sched_debug.html
index 8175ed6513..cdcc96ac0e 100644
--- a/doc/sched_debug.html
+++ b/doc/sched_debug.html
@@ -1,3 +1,7 @@
 
    Scheduling server: debugging
    
 
 
    
+The scheduling server uses assert to verify that arguments to functions have
+valid values. Specifically, assert statements are used to verify that pointers
+are not NULL and lengths are greater than zero. Error messages are also printed
+to stderr, which is routed by Apache to the error log. 
diff --git a/doc/sched_policy.html b/doc/sched_policy.html
index 1ab28a03f8..3a6c6131ec 100644
--- a/doc/sched_policy.html
+++ b/doc/sched_policy.html
@@ -1,4 +1,17 @@
 
    Scheduling server: policy
    
 
 
    
-
+The scheduling server will attempt to send enough work to excede a hosts high
+water mark. If the amount of work the scheduling server is sending excedes four
+weeks, the scheduling server will not attach more work to a scheduler reply. 
+This does not prevent the scheduling server from sending a work unit that takes
+more than four weeks, but merely from attaching more work after a scheduler
+reply has four weeks of work. If a work unit uses more disk resources than a
+host has available, the scheduling server will not attach that work unit. The
+scheduling server estimates the amount of time a work unit will take to
+complete with the formula (number of fpops)/(fpops per second)+(number of
+iops)/(iops per second). The number of fpops and number of iops are 
+provided by the backend when creating the work unit, and the calculation speeds
+are included in a scheduler request. If no work is available, the scheduling
+server sends the message no work available with priority low,
+and requests that the client wait before sending another scheduler request. 
diff --git a/doc/test.html b/doc/test.html
index 09b76bb636..f0b1406d2e 100644
--- a/doc/test.html
+++ b/doc/test.html
@@ -23,10 +23,12 @@ for initializing and testing the entire system:
 
  •  test_concat.php: tests I/O connection using command-line args
 and filenames.
 
  •  test_uc_slow.php: tests checkpoint/restart.
-You have to run the client yourself;
+You have to run the client yourself,
 kill and restart it a few times.
 
  •  test_prefs.php: tests some aspects of preferences.
 
  •  test_api.php: tests to ensure the api is working properly.
+
  •  test_water.php: tests some aspects of water marks.
+
  •  test_rsc.php: tests that scheduling server only sends feasable work units.