Check out the new USENIX Web site. next up previous
Next: Comparison of Replacement Algorithms Up: Experimental Results Previous: Experimental Results

Replacement vs. Fixed Timeouts

It is, in a sense, unfair to compare a replacement policy with a policy that proactively disconnects users even when the modem pool is not fully utilized. A replacement policy is always going to inconvenience fewer users while incurring the same number of busy signals. It is, however, interesting to quantify how much better the replacement approach is in a practical setting. Since fixed-idle-threshold disconnection policies are widespread, we show the results of a single experiment below, just as a point of reference. We will not, however, insist on such comparisons any further in the rest of the paper. If keeping users connected has no cost, the replacement approach clearly results in much less inconvenience for users.

   figure105
Figure 3: Log plot of hard faults for three replacement policies and a fixed idle threshold policy.

Figure 3 shows the numbers of hard faults incurred when simulating a fixed-idle-threshold disconnection policy and three replacement policies for our first Telesys trace. The simulated modem pool has 1,936 modems (this number is 90% of the maximum number of users who are connected simultaneously in this trace). The threshold value, tex2html_wrap_inline596 , varies from 600 to 2700 seconds (10 to 45 minutes). (Recall that tex2html_wrap_inline490 is the minimum idle time before a user becomes eligible for disconnection.) For all values of the threshold, the replacement algorithms incur at least one order of magnitude fewer hard faults.

In examining Figure 3 (as well as figures that follow) it may seem awkward that the number of hard faults can rise for higher thresholds. Recall, however, that the figures shown are produced for tex2html_wrap_inline586 . When the threshold tex2html_wrap_inline490 increases, tex2html_wrap_inline568 also increases, thus causing many soft faults to be considered hard faults.



Yannis Smaragdakis
Tue Apr 25 15:09:47 EDT 2000