[ogsa-rss-wg] Candidate Ordering Language

Soonwook Hwang hwang at grid.nii.ac.jp
Thu Dec 22 02:39:47 CST 2005


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.
> 






More information about the ogsa-rss-wg mailing list