Resource availabilty difference reported by qstat/qconf

[paulu]

I see a difference in the reported availability of a global
consumables, depending on the method to show it. In this particular
case it is about a requestable global consumable named mti_sim_total.

With:
qstat -F | grep gc:mti_sim_total | sort -u

I get:
gc:mti_sim_total=0

With:
SGE_SINGLE_LINE= qconf -se global | grep ^load_values

I see:
mti_sim_total=1

So a difference of 1.

There is also a load sensor involved for this consumable. I know by a
log file it produces that the value reported by the load sensor is 1.

The thing that I want to know is what exactly is reported by qstat -F
and qconf -se.

I always assumed that these were the same, as far as the consumables
go. Now however I am inclined to believe that the load_values reported
by qconf -se truly are the values reported by the load sensor, and
that the gc: values reported by qstat -F are the values of the
internal book keeping of SGE. The latter is the lowest of the values
of the load sensor and the remaining number deduced from the resource
requests (-l options).

Can anyone provide some certainty? Thanks!

[reuti]

Post by paulu
I see a difference in the reported availability of a global
consumables, depending on the method to show it. In this particular
case it is about a requestable global consumable named mti_sim_total.
qstat -F | grep gc:mti_sim_total | sort -u
gc:mti_sim_total=0

The output will change: you will see either gc: or gl:, depending what's the tighter constraint (same for `qhost`).

Post by paulu
SGE_SINGLE_LINE= qconf -se global | grep ^load_values
mti_sim_total=1

This is the plain load value, left untouched.

-- Reuti

Post by paulu
So a difference of 1.
There is also a load sensor involved for this consumable. I know by a
log file it produces that the value reported by the load sensor is 1.
The thing that I want to know is what exactly is reported by qstat -F
and qconf -se.
I always assumed that these were the same, as far as the consumables
go. Now however I am inclined to believe that the load_values reported
by qconf -se truly are the values reported by the load sensor, and
that the gc: values reported by qstat -F are the values of the
internal book keeping of SGE. The latter is the lowest of the values
of the load sensor and the remaining number deduced from the resource
requests (-l options).
Can anyone provide some certainty? Thanks!
--
Paul.
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=303301

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=303387

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

[paulu]

Reuti,

Thanks a lot for the response.

Post by reuti

Post by paulu
I see a difference in the reported availability of a global
consumables, depending on the method to show it. In this
particular case it is about a requestable global consumable
named mti_sim_total.
qstat -F | grep gc:mti_sim_total | sort -u
gc:mti_sim_total=0

The output will change: you will see either gc: or gl:, depending
what's the tighter constraint (same for `qhost`).

With qstat -F I always see gc:, never gl:.

With qhost -F I see some global consumables reported as gc: and some
as gl:. I have read the manual:

'l' - a load value reported for the resource,
'c' - availability derived from the consumable resources facility

However, I cannot figure out why one resource is reported as 'l' and
the other as 'c'. All are defined as global consumable resources in
the same way. And all are reported by the load sensor. I am using SGE
6u8.

Post by reuti

Post by paulu
SGE_SINGLE_LINE= qconf -se global | grep ^load_values
mti_sim_total=1

This is the plain load value, left untouched.

OK, clear.

That then brings me to an additional (final) question: is it possible
to see the available resources, according to just the current resource
requests? So not adjusted by the load reports. Currently, I only can
see if requests have been made which do not actually use the requested
resource (a floating license feature in my case). I would also be able
to see the opposite: using a license feature without the proper
request for it.

Thanks.

[reuti]

Hi,

Post by paulu
Thanks a lot for the response.

Post by reuti

Post by paulu
I see a difference in the reported availability of a global
consumables, depending on the method to show it. In this
particular case it is about a requestable global consumable
named mti_sim_total.
qstat -F | grep gc:mti_sim_total | sort -u
gc:mti_sim_total=0

The output will change: you will see either gc: or gl:, depending
what's the tighter constraint (same for `qhost`).

With qstat -F I always see gc:, never gl:.
With qhost -F I see some global consumables reported as gc: and some
'l' - a load value reported for the resource,
'c' - availability derived from the consumable resources facility
However, I cannot figure out why one resource is reported as 'l' and
the other as 'c'. All are defined as global consumable resources in
the same way. And all are reported by the load sensor. I am using SGE
6u8.

Post by reuti

Post by paulu
SGE_SINGLE_LINE= qconf -se global | grep ^load_values
mti_sim_total=1

This is the plain load value, left untouched.

OK, clear.
That then brings me to an additional (final) question: is it possible
to see the available resources, according to just the current resource
requests? So not adjusted by the load reports.

I think this would be useless: it would show one resource complex free, but as it's limited by a load sensor it would never get scheduled anyway. Only option I see: have a second complex w/o a load sensor and request always both.

Post by paulu
Currently, I only can
see if requests have been made which do not actually use the requested
resource (a floating license feature in my case). I would also be able
to see the opposite: using a license feature without the proper
request for it.

Then use only the load sensor and not a consumable complex. This might lead to race conditions of course, as jobs get scheduled and only thereafter it turns out, that they need a license which might not be available. Is it for FLEXlm or any other license management?

NB: When a job requests a license and is not using it, it would be to educate users to request the right things.

-- Reuti

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=304875

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].