Yo

gotta agree with the traylenator here.  i guess there are two levels of 
confusion: the one about what the actual question is (see the earlier 
mail) or about from whose viewpoint you want to look at it.  You're 
looking at it from the job's point of view: "where am i gonna land if i 
specify these requirements".  The original question seems to me to be 
from the other side: the resource provider's point of view.

Let's see if this helps: your job is a box that needs to be put in some 
warehouse.  Someone calls you and says "can i store this box in your 
warehouse for awhile?"  You ask questions: how big is it?  how much does 
it weigh?  how long do you need us to store it?  Given these answers you 
can consult your Gigantic Excel Spreadsheet and figure out if you can do 
it.  Fine.  No problem.  Probably everybody happy.

Now suppose you have a box broker that is a middleman.  Your users send 
the information about their boxes and requirements, but they send all 
this to the broker.  You advertise that you can take boxes that are max 
1 m by 0.5 m by 0.717 m, weighing no more than 250 kilos, and can store 
them for up to thirteen days in one warehouse, 31 in another.  The 
broker matches boxes coming in from users with your warehouses (and 
others all over the world).

You start getting boxes with notes on them:

please put this one in warehouse 1
please put this one in warehouse 2
....

That's all, no more information.

[ note here the analogy kind of sucks, because at this point an
   intelligent person would just measure the dang box, eliminating
   at least some confusion.  but let's assume our boxadmin is
   a bit dense. ]

If there *was* more information, like "this box weighs 20 kilos and you 
only need to store it for three days", you might choose to store it in 
any of the three warehouses.  Or you might do something intelligent like 
put the big heavy box that says "store for 30 days" underneath a lot of 
light boxes that say "store for four days".  You can't do anything smart 
though if you're only told which warehouse it should go into.

You can easily map this discussion of wall times, cpu times, memory 
requirements, etc. into the queuing and requirements discussion.

A heterogenous pool behind the queues indeed complicates things and I 
could not find a single reference to dealing with this problem (at least 
via PBS), which kind of surprised me.  The heteropool problem just makes 
the situation symmetric: the LRMS doesn't have any idea what kind of job 
it's getting, and the job has no idea what kind of node it's getting.

I guess here I agree with Stephen in that for most things it's not a 
point -- memory is memory, disk is disk.  But the times are special 
since the time unit is different on different machines.

	J "hmm, what if the broker sends you a VO box?" T

Burke, S (Stephen) wrote:
> LHC Computer Grid - Rollout 
> 
>>[mailto:[log in to unmask]] On Behalf Of Jeff Templon
> 
> said:
> 
>>I intepreted the original call for comments to be about A 
>>above, not B 
>>or C.  The question was for A, what else can you think of 
>>besides 'cput' 
>>that you'd want passed from the grid layer into the LRMS layer.
> 
> 
> It seems to me that the cpu (and wallclock) times are unusual in that
> they are properties of the queue, whereas everything else you might
> specify is a property of the WN. (Of couse there's a sub-issue that the
> real requirement is for something like specint-seconds, I doubt anyone
> really wants 5 minutes on any CPU ...) Hence it would probably be better
> to take something like physical memory as a canonical example, and
> regard time limits as a special case. That also implies that your A and
> B are interlinked, if you can't tell that there are higher-spec WNs the
> question of how you specify them is moot ...
> 
> Stephen