run_time mandatory

[radical-cybertools]

run_time mandatory

[mturilli]

Is this equivalent to the wall-time of PBS?

[andre-merzky]

I think so...

[mturilli]

If so, run_time should be considered the upper bound time-limit of the pilot. Or are you thinking about pilots that can aggregate not only multiple jobs, but at different times t and t+n?

[andre-merzky]

I thought about pilots where I don't know the upper bound in advance, so can't specify it sensibly. I understand that I may end up with a pilot which is getting killed by PBS because it exceeds queue max time - but that is then the users responsibility... (or possibly the Troy scheduler's task to pick a queue with long walltimes).

[oleweidner]

It simply won’t work without defining runtime. I think it is perfectly fine that this attribute is mandatory on pilot-framework level. It’s up to you to hide this detail in the higher layers, e.g., in TROY where you have means of inspection and can find out queue properties…

On Dec 11, 2013, at 18:58 , Andre Merzky [email protected] wrote:

I thought about pilots where I don't know the upper bound in advance, so can't specify it sensibly. I understand that I may end up with a pilot which is getting killed by PBS because it exceeds queue max time - but that is then the users responsibility... (or possibly the Troy scheduler's task to pick a queue with long walltimes).

—
Reply to this email directly or view it on GitHub.

[andre-merzky]

Maybe we should address this on saga-python level -- when you run your which commands to get qsub location etc, we can also run a qstat -q to get max queue walltimes, which then can be used as default values if no specific walltime is defined by the user.

I don't think we want our Sinon users to do manually what is easily inspectable automatically:

(ve)[merzky@i136 ~]$ qstat -q | awk -- 'NR < 5 {next}; /[a-z]/ {print $1,$4}'
ib 24:00:00
bravo 24:00:00
bravo-long 168:00:0
fg40 168:00:0
echo 168:00:0
batch 24:00:00
long 168:00:0
provision 24:00:00
delta 24:00:00
b534 168:00:0
systest 24:00:00
reserved 168:00:0
interactive 24:00:00
delta-long 168:00:0

[mturilli]

This is what bundles do for us in TROY. Generally speaking, evaluating the number of pilots required by the given workload and, when possible, slicing the workload across them, is one of the main functionality of Troy. This is why the users use Troy, not to have their pilots killed by PBS. Happy to move this discussion on Troy-devel.

[marksantcroos]

I think on saga-pilot level it makes sense to just specify it.

Btw, you don’t necessarily always want to maximise the runtime, as asking for a long runtime can be a pessimisation on the queuing waiting time if you don’t need all of that runtime.

Gr,

Mark

On 12 Dec 2013, at 5:49 , Ole Weidner [email protected] wrote:

It simply won’t work without defining runtime. I think it is perfectly fine that this attribute is mandatory on pilot-framework level. It’s up to you to hide this detail in the higher layers, e.g., in TROY where you have means of inspection and can find out queue properties…

On Dec 11, 2013, at 18:58 , Andre Merzky [email protected] wrote:

I thought about pilots where I don't know the upper bound in advance, so can't specify it sensibly. I understand that I may end up with a pilot which is getting killed by PBS because it exceeds queue max time - but that is then the users responsibility... (or possibly the Troy scheduler's task to pick a queue with long walltimes).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[andre-merzky]

mturilli: replying in this ticket, even if it is about troy.

Assume we use Troy to implement an application framework which usually submits multiple workloads -- workloads are very similar but the total number is unknown. When the planner receives the first workload, it can derive a useful overlay structure and size -- but it will not be able to determine the overlay lifetime, as for that, it would need to also know about the number of future workloads.

It is a contrived example obviously, just for illustration. The question is if Troy wants to cover workloads which are not time bound initially.

BTW; a better (because realistic) use case is any workload where we cannot pre-determine the TTC of the tasks -- which I think will be a significant fraction of workloads.

I think you are saying that we, using bundles, would pick a queue with long walltimes and use the max walltime. That would work in this case -- so from the Troy perspective you are right. I am not sure if this is a neccesarry constraint on Sinon level...

Just want to mention also that this ticket is a very minor issue -- i just stumbled over it, and wanted to mention it. Not a show stopper or abstraction breaker either way...