Hi Paul,

Thank you for the explanations. Actually this was not the main point of the question asked. I think we can close the discussions. 

The main point was: why a job is running more efficiently using sbatch than salloc.

Thank you all for the contributions. 

- Mike

Sent from my iPhone

On Jul 5, 2023, at 12:33 PM, Paul H. Hargrove <phhargr...@lbl.gov> wrote:


Mike,

I think your definitions are probably in the minority on this list.
To be clear, I am not saying you (or SGE) are wrong, just that the folk here use different terms for what you are asking for.
I think of it like dialects of English where the same food might be a "cookie" or a "biscuit" depending on the local dialect.

To me, "interactive" means "keyboard interactive".

If I want the most immediate access then "immediate" is the term I use.
Fwiw, the `srun` and `salloc` commands have an `--immediate=time` option to bound how long they wait for resources.

It is possible to define an "immediate" or "interactive" (or any other name you may choose) QOS to ensure that interactive jobs are scheduled on a distinct partition of the cluster and/or are given higher priority in scheduling of nodes which are also used for non-interactive jobs.

I've just confirmed that LSF and PBS documentation use the term "interactive" in the same way as Slurm.

-Paul

On Wed, Jul 5, 2023 at 7:06 AM Mike Mikailov <mmikai...@gmail.com> wrote:
Thank you Loris, for the further feedback.

“Reasonable” for SGE is within a few minutes, would be nice if it could be adjusted.

Still interactive means the user has almost immediate access to the system, not queued.

Sent from my iPhone

> On Jul 5, 2023, at 9:43 AM, Loris Bennett <loris.benn...@fu-berlin.de> wrote:
>
> Mike Mikailov <mmikai...@gmail.com> writes:
>
>> Thank you Loris, for the further clarifications. The only question is
>> who will wait forever in interactive mode? And how practical is it?
>>
>> Interactive mode is what its name implies - interactive, not queueing.
>
> To me, "interactive" is the alternative to "batch" - queueing happens
> with both.  Whether I submit an interactive job or a batch job, the job
> can only start if the requested resources are available and the job has
> a sufficiently high priority.
>
> If you have enough nodes, you might be able to spare some to be
> essentially idle most of the time, so that jobs sent to these nodes
> will, in general, start quickly.  If you have a small cluster, this
> might not be an option.
>
>> It would make more sense if the default setting for deadline would be set to a reasonable time not indefinite in Slurm.
>
> One person's "reasonable" may be another person's "ridiculously long".
> A "reasonable time" may even vary for the same person depending on the
> circumstances.  If you submit an interactive job before lunch, you might
> be prepared to wait longer than if the building is going to close in 30
> minutes and you will have to leave.  With '--deadline' you can decide
> case by case.
>
> Cheers,
>
> Loris
>
>> Sent from my iPhone
>>
>>>> On Jul 5, 2023, at 1:43 AM, Loris Bennett <loris.benn...@fu-berlin.de> wrote:
>>>
>>> Mike Mikailov <mmikai...@gmail.com> writes:
>>>
>>>> About the last point. In the case of sbatch the jobs wait in the
>>>> queue as long as it takes until the resources are available. In the
>>>> case of interactive jobs
>>>> (at least using Son of Grid Engine) they fail after a short time if no resources available.
>>>
>>> But you were referring to 'salloc' and not something SGE does.  The
>>> default for 'salloc' is to wait indefinitely.  You can change this
>>> behaviour with the option '--deadline':
>>>
>>>  --deadline=<OPT>
>>>          remove the job if no ending is possible before this deadline
>>>          (start > (deadline - time[-min])).  Default is no deadline.
>>>          Valid time formats are:
>>>          HH:MM[:SS] [AM|PM]
>>>          MMDD[YY] or MM/DD[/YY] or MM.DD[.YY]
>>>          MM/DD[/YY]-HH:MM[:SS]
>>>          YYYY-MM-DD[THH:MM[:SS]]]
>>>          now[+count[seconds(default)|minutes|hours|days|weeks]]
>>>
>>> [snip (36 lines)]
>>>>
>>>> Queuing system  No  Yes 
>>>>
>>>> I am not sure what you mean with the last point, since 'salloc' is also
>>>> handled by the queueing system.  If the resources requested are
>>>> currently not available, 'salloc' will wait until they are.
>>>
>>> [snip (42 lines)]
>>>
>>> --
>>> Dr. Loris Bennett (Herr/Mr)
>>> ZEDAT, Freie Universität Berlin
>>>
> --
> Dr. Loris Bennett (Herr/Mr)
> ZEDAT, Freie Universität Berlin
>



--
Paul H. Hargrove <phhargr...@lbl.gov>
Pronouns: he, him, his
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department
Lawrence Berkeley National Laboratory

Reply via email to