Changes between Version 16 and Version 17 of AppCoprocessor

Timestamp:

Jan 22, 2009, 11:28:56 AM (16 years ago)

Author:

davea

Comment:

--

AppCoprocessor

@@ -11 +11 @@
 
 The BOINC client probes for coprocessors and reports them in scheduler requests.
+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.
 
 == Deploying a coprocessor app ==
@@ -27 +29 @@
 {{{
 bool app_plan(SCHEDULER_REQUEST& sreq, char* plan_class, HOST_USAGE& hu) {
-    if (!strcmp(plan_class, "mt")) {
-        // the following is for an app that can use anywhere
-        // from 1 to 64 threads, can control this exactly,
-        // and whose speedup is .95N
-        // (so on a uniprocessor, we'll use a sequential app
-        // if one is available)
-        //
-        int ncpus, nthreads;
-        bool bounded;
-
-        get_ncpus(sreq, ncpus, bounded);
-        nthreads = ncpus;
-        if (nthreads > 64) nthreads = 64;
-        hu.avg_ncpus = nthreads;
-        hu.max_ncpus = nthreads;
-        sprintf(hu.cmdline, "--nthreads %d", nthreads);
-        hu.flops = 0.95*sreq.host.p_fpops*nthreads;
-        return true;
-    } else if (!strcmp(plan_class, "cuda")) {
+    if (!strcmp(plan_class, "cuda")) {
         // the following is for an app that uses a CUDA GPU
         // and some CPU also, and gets 50 GFLOPS total
@@ -85 +69 @@
  * Allow app_versions to specify min and max requirements (and have a corresponding allocation scheme in the client).
  * Let projects define their own resources, unknown to BOINC, and have "probe" programs (using the assigned-job mechanism) that surveys the resources on each host.
- * Store the resource descriptions in the DB (or maybe flat files), so that you can study your host population.
+