This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf5649?selectedTab=comments at Sun, 06 Nov 2022 19:24:52 GMT SourceForge : artf5649: CPU time elements

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin

JSDL calendar
Search Tracker
Project: JSDL-WG     Trackers > [CLOSED] JSDL v1.0 Errata > View Artifact
Artifact artf5649 : CPU time elements
Tracker: [CLOSED] JSDL v1.0 Errata
Title: CPU time elements
Description:
It's not clear to me whether the intention of IndividualCPUTime and TotalCPUTime are as limits for the job, or as 
resource requirements for the job. 

If they are purely used as limits, then perhaps they should not be RangeValue_Types, but just upper bound types. 

If they are also intended as resource requirements, then they have no value as is, because there is no time period over 
which I can see how many cpu seconds are available. That is, if my machine is on "forever" then I have an infinite 
number of cpu seconds, and this resource requirement is always true. The job might also "run" forever, but that's ok by 
this element's definition.
Submitted By: Chris Smith
Submitted On: 11/30/2006 4:33 PM EST
Last Modified: 06/27/2007 10:56 AM EDT
Closed: 06/27/2007 10:56 AM EDT

Status / Comments Change Log Associations Attachments  
Status  
Group: *
Status:* Closed
Category: *
Customer: *
Priority: * 3
Assigned To: * Donal Fellows
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
Comments
Andreas Savva: 06/27/2007 10:56 AM EDT
  Comment:
Verified in draft 10
  Action: Update
Closed set to 06/27/2007
Status changed from Fixed to Closed
Andreas Savva: 06/26/2007 6:08 AM EDT
  Comment:
Incorporated new proposed text in draft 10
  Action: Update
Status changed from Resolved to Fixed
Andreas Savva: 06/20/2007 11:10 AM EDT
  Comment:
Proposed text seems good. 
  Action: Update
Status changed from Pending to Resolved
Andreas Savva: 06/13/2007 11:05 AM EDT
  Comment:
Suggested replacement text for the 

* IndividualCPUTime 

If this element is used with an upper bound, then this value acts as a ceiling on the number of CPU seconds that a job will consume on an individual 
resource. If the job exceeds this value, the consuming system MAY terminate the job.

If this element is used with a lower bound,  then this value acts as a floor on the number of CPU seconds that a job is guaranteed to consume on an 
individual resource. The consuming system SHOULD NOT terminate the job before the lower bound is reached.

There is an expectation that the required CPU seconds will be consumed within a reasonably contiguous time period.

This element should be considered in conjunction with applicable scheduling attributes, which may defined in other specifications.

* With analogous text for TotalCPUTime
  Action: Update
Donal Fellows: 06/11/2007 11:14 AM EDT
  Comment:
These elements describe resource requirements. Resource requirements may be implemented with limits, but implementors are not constrained to do so (e.
g. when using a virtualization environment, other choices may be possible). By contrast, a CPU time limit (as described in the POSIX extension) means 
exactly that, and that includes all the implied stuff about getting a catchable SIGXCPU signal when the limit is exceeded.

When someone specificies a resource requirement, they give the range of values which are acceptable to them; with CPU times, they'll typically give a 
non-zero lower bound and might or might not give an upper bound (a job pricing model would be needed to persuade people to give a non-infinite upper 
bound, of course, but that's the meaning.) It is up to the batch engine (as modified by any policies) to decide how much CPU time to allocate to a job
; as long as it is in the range given by the user, it is acceptable. If an implementation decides to implement resource management through setting CPU
 time limits, it might decide to set the limit lower than the POSIX limit level requested; in that case it probably shouldn't set the limit to higher 
than the amount allocated. I hope this is clear.

I've no idea how to implement a TotalCPUTime resource. :-)
  Action: Update
Andreas Savva: 05/07/2007 11:47 AM EDT
  Comment:
No consensus on text. Discuss again with Donal and Chris.
  Action: Update
Assigned To changed from Chris Smith to Donal Fellows
Status changed from Fixed to Pending
Andreas Savva: 03/07/2007 4:48 AM EST
  Comment:
I've added the supplied text in draft 2 with some minor editorial changes.
  Action: Update
Status changed from Resolved to Fixed
Chris Smith: 01/25/2007 8:20 PM EST
  Comment:
Here is my suggestion for additional text on...


IndividualCPUTime:

If this element is used with an upper bound, then this value acts as an upper limit on the number of CPU seconds that a job will consume on an 
individual resource. If the job exceeds this limit, the consuming system is free to terminate the job.

If this element is used with a lower bound, indicating a lower limit on the number of CPU seconds that the job will consume on the resource, then the 
evaluation of this element needs to be done in conjunction with another JSDL element or non-JSDL extension element that causes evaluation of this 
limit within a finite time period, or else the lower limit requirement becomes trivially true, as any resource has a theoretical infinite number of 
CPU seconds available.

For example, a lower limit on CPU seconds could  be evaluated within a given period of time if the jsdl-posix:WallClockLimit is provided, where the 
time period is the job's wall clock starting time plus the duration given by jsdl-posix:WallClockLimit.


TotalCPUTime:

If this element is used with an upper bound, then this value acts as an upper limit on the number of CPU seconds that a job will consume on all 
allocated resources. If the job exceeds this limit, the consuming system is free to terminate the job.

If this element is used with a lower bound, indicating a lower limit on the number of CPU seconds that the job will consume on the resource, then the 
evaluation of this element needs to be done in conjunction with another JSDL element or non-JSDL extension element that causes evaluation of this 
limit within a finite time period, or else the lower limit requirement becomes trivially true, as any resource has a theoretical infinite number of 
CPU seconds available.

For example, a lower limit on CPU seconds could  be evaluated within a given period of time if the jsdl-posix:WallClockLimit is provided, where the 
time period is the job's wall clock starting time plus the duration given by jsdl-posix:WallClockLimit.
  Action: Update
Andreas Savva: 01/17/2007 9:42 AM EST
  Comment:
Add clarification that there is a period applied so that the lower limit makes sense. The definition of this period is not part of 1.0 or 1.1 (
scheduling).

upper bound is ok without any period.

  Action: Update
Assigned To set to Chris Smith
Status changed from Open to Resolved
Chris Smith: 11/30/2006 4:33 PM EST
  Action: Create


 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf5649?selectedTab=comments at Sun, 06 Nov 2022 19:24:52 GMT