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?selectedTab=history at Sun, 06 Nov 2022 19:04:47 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  
 (4 Items)
Field Old Value New Value Date Performed By
Status
Open
Closed
03/14/2008 12:28 PM EDT Sergio Andreozzi
Closed 03/14/2008 03/14/2008 12:28 PM EDT Sergio Andreozzi
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.
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.
03/11/2008 9:32 AM EDT Sergio Andreozzi
Description
 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.
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.
03/11/2008 9:31 AM EDT Sergio Andreozzi

 
 


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?selectedTab=history at Sun, 06 Nov 2022 19:04:47 GMT