Project

General

Profile

Feature #10715

Add time length option

Added by Joe Boyd over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
10/29/2015
Due date:
% Done:

0%

Estimated time:
Stakeholders:
Duration:

Description

As discussed at the jobsub meeting, add a jobsub option where users can specify how long their job should run. I think short, medium, and long is good enough. We should then be able to put stuff into the frontend to make sure those jobs only run in the appropriate glideins.

History

#1 Updated by Joe Boyd over 5 years ago

Those length strings should be mapped via the jobsub config file to actual integers that we'll then use in the frontend to make sure jobs run where they are supposed to run. We may want to change the timing attached to those strings over time so they should be in the config file. If the user specifies an integer instead of short, medium, or long then it should just be put directly into the classad for the value so we have the option of more customized run times.

#2 Updated by Joe Boyd over 5 years ago

There should also be an item in the config file for a default job length time that will get put into the job classad if the user doesn't specify anything.

#3 Updated by Dennis Box over 5 years ago

  • Target version set to v1.1.9

#4 Updated by Kenneth Herner over 5 years ago

The variable name that I have been using in the frontend matching is JOB_EXPECTED_MAX_LIFETIME.

#5 Updated by Dennis Box over 5 years ago

So this integer value for JOB_EXPECTED_MAX_LIFETIME in the classad, I assume this is in seconds?

What are good starting values for short, medium, long? I will start with 6 hours, 24 hours, 7 days converted to seconds until I hear otherwise.

Dennis

#6 Updated by Joe Boyd over 5 years ago

The short, medium, and long should be configurable options out of the config file but my current thought is that they'd be 6, 12, and 24 hours (yes converted to seconds for the classad).

#7 Updated by Dennis Box over 5 years ago

here is the help output:
--expected-lifetime=EXPECTED_LIFETIME
Expected lifetime of the job. Used to match against
resources advertising that they have
REMAINING_LIFETIME seconds left. The shorter your
EXPECTED_LIFTIME is, the more resources (aka slots,
cpus) your job can potentially match against and the
quicker it should start. If your job runs longer than
EXPECTED_LIFETIME it may be killed by the batch
system. If your specified EXPECTED_LIFETIME is too
long your job may take a long time to match against a
resource a sufficiently long REMAINING_LIFETIME.
Valid inputs for this parameter are 'short', 'medium',
'long', or an integer which represents
EXPECTED_LIFETIME in seconds. The values for
'short','medium',and 'long' are configurable by Grid
Operations, they currently are '6 hours' , '12 hours'
, and '24 hours' but this may change in the future.
Default value of EXPECTED_LIFETIME is 6 hours.

when --expected-lifetime medium is invoked this shows up in the submit file:

+JOB_EXPECTED_MAX_LIFETIME = 43200

If you want anything changed let me know.

Dennis

#8 Updated by Dennis Box over 5 years ago

  • Status changed from New to Feedback
  • Assignee changed from Dennis Box to Joe Boyd

see comments earlier in ticket, if this is expected behavior I will merge.

#9 Updated by Joe Boyd over 5 years ago

Shouldn't EXPECTED_LIFETIME be specified in hours instead of seconds to make it easier for the user? You can convert it to seconds to put it in the job. This isn't a precise measurement. Due to data handling dealays and differences in cpu speeds the time a job takes to run varies quite a bit. If the user just specifies the hours that's close enough.

The length of short, medium, long, and the default are all in a config file we can easily change correct?

#10 Updated by Dennis Box over 5 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF