| |
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.
|
