Aggregation Methods

At the time a DIET service is defined, an aggregation method - the logical mechanism by which SeD responses are sorted - is associated with the service; the default behavior was described in Section 9.2.

If application-specific data are supplied (i.e., the estimation function has been redefined), an alternative method for aggregation is needed. Currently, a basic priority scheduler has been implemented, enabling an application developer to specify a series of performance values that are to be optimized in succession. A developer may implement a priority scheduler using the following interface:

The diet_profile_desc_aggregator and diet_aggregator_set_type functions fetch and configure the aggregator corresponding to a DIET service profile, respectively. In particular, a priority scheduler is declared by invoking the latter function with DIET_AGG_PRIORITY as the agg parameter. Recall that from the point of view of an agent, the aggregation phase is essentially a sorting of the server responses from its children. A priority scheduler logically uses a series of user-specified tags to perform the pairwise server comparisons needed to construct the sorted list of server responses.

To define the tags and the order in which they should be compared, four functions are introduced. These functions, of the form diet_aggregator_priority_*, serve to identify the estimation values to be optimized during the aggregation phase. The _min and _max forms indicate that a standard performance metric (e.g., time elapsed since last execution, from the diet_estimate_lastexec function) is to be either minimized or maximized, respectively. Similarly, the _minuser and _maxuser forms indicate the analogous operations on user-supplied estimation values. Calls to these functions indicate the order of precedence of the tags.

Each time two server responses need to be compared, the values associated with the tags specified in the priority aggregator are retrieved. In the specified order, pairs of corresponding values are successively compared, passing to the next tag only if the values for the current tag are identical. If one server response contains a value for the metric currently being compared, and another does not, the response with a valid value will be selected. If at any point during the treatment of tags both responses lack the necessary tag, the comparison is declared indeterminate. This process continues until one response is declared superior to the other, or all tags in the priority aggregator are exhausted (and the responses are judged equivalent).

The DIET Team - Mer 29 nov 2017 15:13:36 EST