Changes between Version 8 and Version 9 of AppCoprocessor

Timestamp:

Mar 12, 2008, 2:35:41 PM (18 years ago)

Author:

davea

Comment:

--

AppCoprocessor

@@ -9 +9 @@
 i.e., an application using a coprocessor has it locked while the app is in memory,
 even if the app is suspended by BOINC or descheduled by the OS.
-
-== Proposed design ==
 
 The BOINC client probes for coprocessors and reports them in scheduler requests.
@@ -25 +23 @@
 }}}
 
-An app_version record (in the server DB) has a character string field '''class'''.
-
-The scheduler is linked with a project-supplied function
-{{{
-bool analyze_app(HOST&, char* class, HOST_USAGE&);
-
-struct HOST_USAGE {
-   COPROCS coprocs;   // coprocessors used by the app (name and count)
-   double ncpus;      // #CPUs used by app (may be fractional)
-   double flops;      // estimated FLOPS
-   char opaque[256];  // passed to the app in init_data.xml
-};
-}}}
-The HOST argument describes the host's CPU(s),
-and includes a field 'coprocs' listing its coprocessors.
-
-The function returns true if the host's resources are sufficient for the app version.
-If true, it populates the HOST_USAGE structure.
-
-When deciding whether to send a job to a host,
-the scheduler examines all latest-version app_versions for the platform,
-and selects the one for which flops is greatest.
-
-The scheduler reply includes, for each app version, an XML encoding of HOST_USAGE.
-
-The client keeps track of coprocessor allocation, i.e. how many instances of each are free.
-It only runs an app if enough instances are available.
-
-The client uses app_version.usage.flops to estimate job completion times.
 
 == Questions ==