Check out the new USENIX Web site.


Next:
Category 1: Single action Up: Polus : Growing Storage Previous: Experimental Setup


Experimental Analysis

The experimental analysis consists of a quantitative comparison of Polus and Rule-based systems for different system states. During evaluation, the values (thresholds and action invocation) for rule-based systems are assumed to be correct and empirically obtained from prior runs. The file system is driven by a trace generator that imposes different states on the system. The generated state is a triplet of the form: Workload characteristics, Available Resources, Goals . The values for the goals are different than their current values. For each of these system states, we compare the response of both Polus and an ECA based rule system. Table 3 categorizes the possible system state.

Table 3: Categorizing the possible system states

Categories

Description

Example (File system simulator)

Category1: Single action applicable

The system states in this category are such that only a single candidate action is applicable, i.e., searching the specifications leads to a single candidate action

Workload: Sequential, read dominated with read/write ratio of 0.9, avg. queue-depth = 6 Current Throughput = 80 MBps Goal = 100 MBps Polus specification search: The only action that becomes applicable is Prefetching.

Category 2: Multiple actions applicable (they appear to have similar preconditions and/or implications)

In this category more than one action have similar preconditions and/or implications and are indistinguishable. In reality, these actions are not similar This category becomes increasingly common during initial bootstrapping, i.e., the system hasn't learnt values for preconditions and implications

Workload: Read dominated, sequential/random ratio = 0.2, average queue-depth = 8. Current Throughput = 80 MBps Goal = 100 MBps Polus specification search: Prefetching and Replication are selected as candidate actions. In reality Prefetching is not applicable as the workload is not sequential, but Polus does not have the threshold value for the sequential/random ratio in prefetch specifications

Category 3: More than one goal not met

In this category, more than one action needs to be invoked as a single action cannot satisfy the goal requirements

Workload: Sequential, read/write= 0.3 Current Throughput = 80 MBps Goal = 100 MBps , Current Latency = 6msec Goal = 4.5 msec Polus specification search: Prefetching and Clean delay are both invoked as the former improves throughput while the later improves latency

Category 4: Recurrent action invocation (One action, leads to chaininvocation of actions)

In this category, invocation of an action leads to a chain-invocation of a series of actions. Ability to detect and prevent recurrent action invocation is a required property of the management software

Workload: Trigger for data backup with window = 4 hours Polus specification search: Theoretically, backup can be invoked since the goals are being met. But invoking backup at this time will cause latency goals to be overshot

Category 5: No action applicable (Negation of previous actions required)

Actions are negated under two scenarios: to make resources available for another actions, and the workload preconditions change

Workload: Changes from large block sequential to small block random Polus specification search: Prefetching hurts performance as memory and storage resources are used for acquiring data that is never used


The analysis of Polus and ECA for each of the categories is described as follows:


Subsections

·          



Next:
Category 1: Single action Up: Polus : Growing Storage Previous: Experimental Setup

2004-02-14