Changes between Version 23 and Version 24 of CreditNew

Timestamp:

Mar 9, 2010, 9:41:25 PM (15 years ago)

Author:

davea

Comment:

--

CreditNew

@@ -107 +107 @@
 but addresses its problems in a new way.
 
-When a job is issued to a host, the scheduler specifies usage(J,D),
-J's usage of processing resource D:
-how many CPUs and how many GPUs (possibly fractional).
+When a job J is issued to a host,
+the scheduler specifies flops_est(J),
+a FLOPS estimate based on the resources used by the job
+and their peak speeds.
 
 If the job is finished in elapsed time T,
@@ -119 +120 @@
 Notes:
 
+ * PFC(J) is 
  * We use elapsed time instead of actual device time (e.g., CPU time).
    If a job uses a resource inefficiently
@@ -130 +132 @@
    dynamically determines the CPU usage.
    For now, though, we'll just use the scheduler's estimate.
+ * For projects (CPDN) that grant partial credit via
+   trickle-up messages, substitute "partial job" for "job".
+   These projects must include elapsed time,
+   app version ID, and FLOPS estimate in the trickle message.
 
 The granted credit for a job J is proportional to PFC(J),
@@ -384 +390 @@
 so we'll move "max_results_day" from the host table to host_app_version.
 
+== Anonymous platform ==
+
+For anonymous platform apps, since we don't necessarily
+know anything about the devices involved,
+we don't try to estimate PFC.
+Instead, we give the average credit for the app,
+scaled by the job size.
+
+The server maintains host_app_version record for anonymous platform,
+and it keeps track of elapsed time statistics there.
+These have app_version_id = -1 for CPU, -2 for NVIDIA GPU, -3 for ATI.
+
+== App plan functions ==
+
+App plan functions no longer have to make a FLOPS estimate.
+They just have to return the peak device FLOPS.
+
+The scheduler adjusts this,
+using the elapsed time statistics,
+to get the app_version.flops_est it sends to the client
+(from which job durations are estimated).
+
 == Job runtime estimates ==
 
@@ -450 +478 @@
 == Compatibility ==
 
+