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/artf6146?nav=1&selectedTab=comments at Sun, 06 Nov 2022 11:34:03 GMT SourceForge : artf6146: MaxCPUTime and normalization

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: GLUE     Trackers > GLUE 2.0 Specification > View Artifact
Artifact artf6146 : MaxCPUTime and normalization
Tracker: GLUE 2.0 Specification
Title: MaxCPUTime and normalization
Description:
from Stephen Burke:

On the computing part I should pass on a comment I got from Jeff Templon about the queue time limits (MaxCPUTime etc). 
Many sites normalise those times to some standard SI2K value, so the actual time limit in wallclock seconds is not the 
same as the published value, and indeed may vary from one WN to another if they have different processors. Jeff's view (
which I tend to agree with) is that time should be time, and if the schema defines something as a time limit in seconds 
then people should publish the actual limit and not a scaled value. Also if the schema is going to allow publication of 
many different benchmarks then it would anyway not be obvious which one is used for normalisation. How should we deal 
with this? At any rate the schema should define its attributes clearly - if time limits may be scaled then we should say
 so explicitly.
Submitted By: Sergio Andreozzi
Submitted On: 03/11/2008 9:30 AM EDT
Last Modified: 03/14/2008 12:28 PM EDT
Closed: 03/14/2008 12:28 PM EDT

Status / Comments Change Log Associations Attachments  
Status  
Status:* Closed
Category: * specification
Priority: * 3
Assigned To: * None
Reported in Release: *
Fixed in Release: *
Comments
Sergio Andreozzi: 03/14/2008 12:28 PM EDT
  Comment:
discussed in this telecon:
https://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting20080314_2

and agreed upon a solution
  Action: Update
Closed set to 03/14/2008
Status changed from Open to Closed
Sergio Andreozzi: 03/11/2008 9:32 AM EDT
  Action: Update
Description changed from
from Stephen Burke:

On the computing part I should pass on a comment I got from Jeff Templon about the queue time limits (MaxCPUTime etc). 
Many sites normalise those times to some standard SI2K value, so the actual time limit in wallclock seconds is not the 
same as the published value, and indeed may vary from one WN to another if they have different processors. Jeff's view (
which I tend to agree with) is that time should be time, and if the schema defines something as a time limit in seconds 
then people should publish the actual limit and not a scaled value. Also if the schema is going to allow publication of 
many different benchmarks
then it would anyway not be obvious which one is used for normalisation. How should we deal with this? At any rate the 
schema should define its attributes clearly - if time limits may be scaled then we should say so explicitly.
to
from Stephen Burke:

On the computing part I should pass on a comment I got from Jeff Templon about the queue time limits (MaxCPUTime etc). 
Many sites normalise those times to some standard SI2K value, so the actual time limit in wallclock seconds is not the 
same as the published value, and indeed may vary from one WN to another if they have different processors. Jeff's view (
which I tend to agree with) is that time should be time, and if the schema defines something as a time limit in seconds 
then people should publish the actual limit and not a scaled value. Also if the schema is going to allow publication of 
many different benchmarks then it would anyway not be obvious which one is used for normalisation. How should we deal 
with this? At any rate the schema should define its attributes clearly - if time limits may be scaled then we should say
 so explicitly.

Sergio Andreozzi: 03/11/2008 9:31 AM EDT
  Action: Update
Description changed from
 On the computing part I should pass on a comment I got from Jeff Templon about the queue time limits (MaxCPUTime etc). 
Many sites normalise those times to some standard SI2K value, so the actual time limit in wallclock seconds is not the 
same as the published value, and indeed may vary from one WN to another if they have different processors. Jeff's view (
which I tend to agree with) is that time should be time, and if the schema defines something as a time limit in seconds 
then people should publish the actual limit and not a scaled value. Also if the schema is going to allow publication of 
many different benchmarks
then it would anyway not be obvious which one is used for normalisation. How should we deal with this? At any rate the 
schema should define its attributes clearly - if time limits may be scaled then we should say so explicitly.
to
from Stephen Burke:

On the computing part I should pass on a comment I got from Jeff Templon about the queue time limits (MaxCPUTime etc). 
Many sites normalise those times to some standard SI2K value, so the actual time limit in wallclock seconds is not the 
same as the published value, and indeed may vary from one WN to another if they have different processors. Jeff's view (
which I tend to agree with) is that time should be time, and if the schema defines something as a time limit in seconds 
then people should publish the actual limit and not a scaled value. Also if the schema is going to allow publication of 
many different benchmarks
then it would anyway not be obvious which one is used for normalisation. How should we deal with this? At any rate the 
schema should define its attributes clearly - if time limits may be scaled then we should say so explicitly.

Sergio Andreozzi: 03/11/2008 9:30 AM EDT
  Action: Create


 
 
 
< Previous
 
 
Next >
 


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/artf6146?nav=1&selectedTab=comments at Sun, 06 Nov 2022 11:34:03 GMT