[ogsa-rss-wg] Candidate Ordering Language

[Mathias Dalheimer]

Hi all,

this is looking good to me. I think it is the right way to start with 
something simple. In fact, I am doing almost the same here: I don't have 
a general language but a scoring model that takes only wheights as 
parameters. And I use relative scores during the calculation, not 
absolute values. But this seems more powerful to me, yet simple enough 
to implement.

Donal: I think we agree on your proposal. (If there's anyone against it, 
please stand up and mail your arguments ;-)) Do you have a document 
describing it?

-Mathias


Soonwook Hwang wrote:
> Thanks Ramin and Donal for clarification.
> I agree with both of you that at this point
> in time it shouldn't be a problem with we
> focusing on not too much complicated language
> like the one Donal had in mind. Sounds good to
> me :-)
> 
> Regards,
> Soonwook
> 
>>-----Original Message-----
>>From: owner-ogsa-rss-wg at ggf.org [mailto:owner-ogsa-rss-wg at ggf.org] On
> 
> Behalf
> 
>>Of Donal K. Fellows
>>Sent: Wednesday, December 21, 2005 8:51 PM
>>To: ogsa-rss-wg at ggf.org
>>Subject: Re: [ogsa-rss-wg] Candidate Ordering Language
>>
>>Ramin Yahyapour wrote:
>>
>>>I assume Donal just want to be able to calculate with time
>>>as well as with other scalar values in this ordering language.
>>>That means, you might want to write
>>>"order by (x*starttime + y*CPU#)"
>>>In that case it is essential how starttime is mapped to a scalar
>>>value.
>>
>>Exactly. The only other way is to assume some standard "time zero" but
>>that's even less pleasant in practice. Base times are just easier to
>>work with.
>>
>>
>>>I assume Donal is trying to model an individual objective function
>>>for a candidate request. In this request someone may specify some
>>>complex function which can be evaluated to get a scalar value for
>>>each candidate. This value can be used for ordering.
>>
>>Yes.
>>
>>
>>>Otherwise, the language is fine for me.
>>>At our site we did a similar approach in the past. However, we built a
> 
> richer
> 
>>>language in which we allowed conditional statements (if/then).
>>>Assuming that part of your ordering formulation might depend on the
>>>availability of certain resource features you might shift your weights
>>>and the complete function. Let's say, if memory is below 4GB you would
>>>put more weight on this feature, if it is above, you might focus on
> 
> other
> 
>>>values like price or responsetime.
>>
>>Actually, you can effectively do this using the result of the <exists>
>>term (a zero-or-one value):
>>
>>  <sum>
>>    <product>
>>      <exists> //Memory[. < 4000000000] </exists>
>>      ...
>>    </product>
>>    <product>
>>      <exists> //Memory[. >= 4000000000] </exists>
>>      ...
>>    </product>
>>  </sum>
>>
>>Or something like that.
>>
>>
>>>But anyway, we should not make this language too complicated at this
> 
> point.
> 
>>>Thus I would suggest to restrict on basic features. Adding more
> 
> complexity
> 
>>>later should not be a problem here.
>>
>>Agreed.
>>
>>Donal.
>>
> 
> 
> 


-- 
______________________________________________________________________
Dipl.-Wirtsch. Ing. (Inform.) Mathias Dalheimer
Fraunhofer Institut fuer Techno- und Wirtschaftsmathematik (ITWM)
Europaallee 10
67657 Kaiserslautern, Germany

Phone +49(0)631/303-1827 | mailto:dalheimer at itwm.fraunhofer.de
Fax   +49(0)631/303-1877 |
______________________________________________________________________