Fig. 1. A task scheduler controls how a resource (physical or virtual) is shared by a number of competing flows. A controller sets the weights of the flows and the degree of concurrency Din the resource, based on feedback about the performance of the flows. The aim is to meet the SLAs of the flows while maximizing the utilization of the resource.

Fig. 2. When weights change in SFQ, there exist intervals in which a flow receives no service independent of its weight setting. The white blocks depict task execution; the gray blocks depict backlog but no execution.

Fig. 3. Example showing that it is possible to construct an unbounded number of consecutive intervals during which there is a flow that receives no service, even though it has non-zero weight.

Fig. 4. Demonstrates the need to rapidly adjust flow weights and D. The graph on the left shows how two different weights values produce very different end-to-end latencies for a flow. The graph on the right shows how two different settings of Dresult in different latencies.

Fig. 5. Sensitivity analysis of the unfairness of SFQ(D) and C-SFQ(D) against weight settings and changes during a run of 1000 intervals. The graph on the left shows the CDF of unfairness for all the intervals of a run (the x-axis is in logarithmic scale). The graph on the right shows unfairness against the relative weight changes (both axes are in logarithmic scale).

Fig. 6. Analysis of the effects of the degree of concurrency D to C-SFQ(D). The graph on the left shows the relation between unfairness and values of D. The graph on the right shows the aggregate throughput and the end-to-end latency obtained from the service for different values of D. The dots are the median values and the error bars show the 5th and the 95th percentile of the measurements.

Fig. 7. Demonstrating the ability of SFQ(D) and C-SFQ(D) to meet performance goals when the STR controller from Section 2.2 sets the weights every 1 s. The two graphs show latency and unfairness.

Frequently used symbols in this paper