Minimizing Energy for Wireless Web Access with
Bounded Slowdown
Ronny Krashinsky and Hari Balakrishnan
MIT Laboratory for Computer Science
200 Technology Square, Cambridge, MA 02139
ronny, hari
@lcs.mit.edu
Abstract
On many battery-powered mobile computing devices, the
wireless network is a significant contributor to the total en-
ergy consumption. In this paper, we investigate the in-
teraction between energy-saving protocols and TCP perfor-
mance for Web-like transfers. We show that the popular
IEEE 802.11 power-saving mode (PSM), a “static” protocol,
can harm performance by increasing fast round trip times
(RTTs) to 100 ms; and that under typical Web browsing work-
loads, current implementations will unnecessarily spend en-
ergy waking up during long idle periods.
To overcome these problems, we present the Bounded-
Slowdown (BSD) protocol, a PSM that dynamically adapts to
network activity. BSD is an optimal solution to the prob-
lem of minimizing energy consumption while guaranteeing
that a connection’s RTT does not increase by more than a
factor
over its base RTT, where
is a protocol parameter
that exposes the trade-off between minimizing energy and
reducing latency. We present several trace-driven simula-
tion results that show that, compared to a static PSM, the
Bounded-Slowdown protocol reduces average Web page re-
trieval times by 5–64%, while simultaneously reducing energy
consumption by 1–14% (and by
compared to no power
management).
Categories and Subject Descriptors
C.2.1 [Computer-Communication Networks]: Network
Architecture and Design—Wireless communication; C.2.5
[Computer-Communication Networks]: Local and Wide-
Area Networks—Internet
General Terms
Algorithms, Design, Measurement, Performance.
Keywords
Wireless, protocols, energy saving, power saving, bounded
slowdown, IEEE 802.11, TCP, HTTP, Web.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MOBICOM’02, September 23–28, 2002, Atlanta, Georgia, USA.
Copyright 2002 ACM 1-58113-486-X/02/0009 ...$5.00.
1. Introduction
The capabilities of mobile computing devices are often lim-
ited by the size and lifetime of the batteries that power them.
As a result, minimizing the energy usage of every compo-
nent in a mobile system is an important design goal. Wireless
network access is a fundamental enabling feature for many
portable computers, but if not optimized for power con-
sumption, the wireless network interface can quickly drain
a device’s batteries. This paper seeks to minimize the energy
consumed by the wireless network interface for a mobile de-
vice generating request/response traffic (e.g., while brows-
ing the Web) over a reliable transport protocol such as TCP.
We investigate several interactions between energy-saving
mechanisms and network performance, and show that un-
derstanding these interactions enables better energy-saving
protocols to be designed that have provable performance-
energy trade-offs.
Many wireless network interfaces, especially wireless
LAN cards, consume a significant amount of energy not only
while sending and receiving data, but also when they are idle
with their radios powered up and able to communicate [3, 5,
7, 11, 15]. However, because wireless applications typically
use the network in bursts, wireless interfaces are designed so
they can be disabled when not in use to save energy. In this
sleep mode, the radio is turned off, and the device has no way
to determine when data is being sent to it over the wireless
network link. This breaks the “always on” abstraction con-
venient for transport protocols such as TCP, where a node
should be able to receive data from the network at any time.
Therefore, any energy-saving protocol that puts the network
interface in sleep mode must have a mechanism to handle
the resulting communication outage.
As an example, consider the popular IEEE 802.11 wireless
LAN specification, which describes a power-saving mode
(PSM) that periodically turns the network interface off to
save energy, and on to communicate [9]. In the so-called in-
frastructure mode (as opposed to the ad hoc network mode),
a mobile device communicates with a wired access point
(AP). When 802.11 PSM is enabled, the AP buffers data
destined for the device. Once every BeaconPeriod, typically
100 ms, the AP sends a beacon containing a traffic indication
map (TIM) that indicates whether or not the mobile device
has any data waiting for it. The mobile device wakes up to
listen to beacons at a fixed frequency and polls the AP to re-
ceive any buffered data. Typically, it listens to every bea-
con, but the mobile device can also be configured to skip Lis-
tenInterval beacons between listen times. Whenever the AP
sends data to the mobile device, it indicates whether or not
1
there is more data outstanding, and the mobile device goes
to sleep only when it has retrieved all pending data from the
AP. When the mobile device itself has data to send, it can
wake up to send the data without waiting for a beacon.
The 802.11 PSM is an example of a static power-saving al-
gorithm, since it does not adapt the sleep and awake dura-
tions to the degree of network activity; we will refer to it
as PSM-static in this paper. We find that while PSM-static
does quite well in saving energy, it does so at significant per-
formance cost. In Section 2, we demonstrate that the round
trip time (RTT) of a TCP connection can increase substan-
tially with PSM-static, since the effect is to round up the RTT
to the nearest 100 ms. This has an especially adverse impact
on short TCP connections, whose performance is dominated
by the connection RTT. We also find that an interesting inver-
sion effect can occur, where under some conditions, the time
to transfer a file over a wireless network running PSM-static
increases when the bandwidth of the wireless link increases!
Furthermore, with PSM-static, the power consumed while
sleeping and listening for beacons dominates the total en-
ergy consumption if the network is accessed only sporadi-
cally. Section 3 shows that for Web workloads, the long (but
randomly distributed) idle periods (“think time”) end up be-
ing most important in terms of energy usage, and that PSM-
static does not handle this situation well.
A PSM protocol addresses the following fundamental
question: When should a wireless interface go to sleep, and when
should it be awake? Based on our observations of the adverse
and unexpected interactions that occur when a TCP connec-
tion is superimposed on PSM-static, we consider the prob-
lem of optimizing energy consumption under the constraint
that interactive request/response performance does not de-
grade by more than a known amount. Specifically, we ad-
dress the following problem: Find an algorithm that minimizes
energy consumption using the sleep and wake-up primitives such
that any RTT does not exceed
, where
is the origi-
nal RTT and
is a tunable parameter that controls the maximum
percentage slowdown.
Our solution to this problem results in the Bounded-
Slowdown (BSD) protocol, described in Section 4. The idea is to
adapt the sleep durations depending on past activity, so that
no RTT is lengthened by more than a factor
, which exposes
the performance-energy trade-off in a provable manner. This
also allows the network interface to sleep for longer periods
of time when there is no activity, thereby reducing the energy
consumed while listening to beacons. In fact, for future net-
work cards, this method could allow the network interface to
go into a deeper sleep mode and save more energy.
Section 5 presents trace-driven simulations, using power
parameters from a commercially available 802.11b card, to
evaluate the effectiveness of the BSD protocol as a function
of
and compare it to PSM-static for real-world Web traffic.
We find that BSD tightly bounds the performance slowdown
of Web retrieval times in all cases, and also often beats PSM-
static in terms of energy consumption. For example, PSM-
static reduces energy by
compared to no PSM, but does
this at the cost of increasing average Web page retrieval times
by 16–232% for network round trip times of 80 ms down to
10 ms. When
, BSD increases average Web page re-
trieval times by only 11–19% over the base performance with
no PSM, and simultaneously uses 1–14% less energy than
PSM-static (and up to
less than no PSM)—both its per-
formance and energy usage are always better than the 802.11
PSM. When
, the BSD protocol essentially eliminates
the slowdown in Web page retrieval times while only using
up to 13% more energy than PSM-static.
The performance benefits of BSD over PSM-static are most
significant when the TCP connection RTT is much smaller
than 100 ms (the beacon period). We note that with the in-
creasing deployment of Web content distribution networks
(CDNs), server replication systems, Web proxies, and caches,
the RTT for Web TCP connections is often small, especially
for popular sites where CDNs and replica abound. For exam-
ple, from both MIT on the east coast of the U.S., and Berke-
ley on the west coast, RTTs to several popular sites such as
Google, Yahoo, CNN, etc. are less than 30 ms most of the
time. In another common wireless network scenario, users
often transfer or synchronize files (e.g., email) between a mo-
bile device and a local server, and the base connection RTT is
a few milliseconds. Although the performance of PSM-static
could be improved by reducing the 100 ms beacon period,
this would lead to significantly higher energy consumption
(we discuss this in Section 5.3). We therefore believe that be-
cause of the trend toward smaller connection RTTs, the BSD
protocol will be especially useful in bounding performance
slowdown while saving considerable energy.
We discuss related work in Section 6 and conclude with a
summary of our results in Section 7.
2. TCP Performance over PSM-static
TCP is the transport layer of choice for the majority of In-
ternet applications. Its performance is therefore a critical con-
sideration in the design of any network component. This sec-
tion evaluates the impact of PSM-static on TCP performance.
During the initial slow-start phase of a TCP connection,
the RTT dominates the overall transfer time for data. Since
most TCP connections on the Internet are smaller than a few
tens of kilobytes [8, 13], RTTs are a critical determinant of
Web browsing performance. In this section, we analyze the
impact that PSM-static has on the first RTT of a connection,
then investigate the impact of PSM-static on RTTs for subse-
quent packets in a TCP transfer, then present experimental
measurements of TCP transfers, and finally discuss an emer-
gent performance inversion effect caused by PSM-static.
2.1 PSM-static Impact on RTT
With PSM-static enabled, the network interface enters a
sleep state whenever it is not sending or receiving data.
When the mobile device has data to send (e.g., a TCP SYN
or ACK packet, a TCP data packet containing a Web request,
etc.), it can wake the network interface up at any time. How-
ever, the network interface will go to sleep as soon as this
data has been transmitted to the AP. When the response data
arrives from the server after some delay, it must be buffered
at the AP until the next beacon occurs. This delay increases
the observed RTT for the connection.
If the mobile device initiates a request/response transac-
tion, the observed RTT depends on when it sends the request
data relative to the beacon period. For example, with an ac-
tual RTT of 20 ms and a beacon period of 100 ms, if the mobile
device sends the request immediately after a beacon, the re-
sponse will be buffered at the AP and received after the next
beacon; thus the observed RTT will be 100 ms. If the mobile
device sends the request 79 ms after a beacon, the AP will
receive the response just before the next beacon and the ob-
served RTT will be just over 20 ms. However, if the mobile
2
0 50 100
0
50
100
150
200
250
observed RTT (ms)
actual RTT = 20 ms
0 50 100
0
50
100
150
200
250
request time after beacon (ms)
actual RTT = 80 ms
0 50 100
0
50
100
150
200
250
actual RTT = 120 ms
0 50 100
1
2
3
4
5
6
RTT slowdown
0 50 100
1
2
3
4
5
6
request time after beacon (ms)
0 50 100
1
2
3
4
5
6
Figure 1: Slowdown due to PSM-static (the 802.11 PSM)
for the first RTT of a TCP connection. The upper graphs
show how the observed RTTs vary with how long after a
beacon the request is sent. The lower graphs show the RTT
slowdown (the observed RTT divided by the actual RTT).
0 50 100 150 200 250 300
0
100
200
300
actual RTT (ms)
observed RTT (ms)
0 50 100 150 200 250 300
1
10
100
actual RTT (ms)
RTT slowdown
5ms
80ms
50ms
Figure 2: Slowdown due to PSM-static for initial RTTs of a
TCP connection (excluding the first RTT). The upper graph
shows how the observed RTTs vary with the actual RTT.
The lower graph shows the RTT slowdown.
device sends the request 81 ms after a beacon, the AP will re-
ceive the response just after the next beacon and will have
to buffer the data until the subsequent beacon; the observed
RTT will be 120 ms, a factor of 6 slowdown. Figure 1 shows
the impact of PSM-static on three example RTTs. The fig-
ure shows the observed RTTs and the slowdown compared
to the actual RTT (the observed RTT divided by the actual
RTT). The PSM-static slowdown is greatest for smaller RTTs.
PSM-static similarly affects RTTs when the mobile device
responds to a request. In this case, the observed RTT depends
on when the request arrives at the AP relative to the beacon
period.
2.2 PSM-static Impact on TCP
When TCP is run over PSM-static, the initial RTT for a con-
nection depends on when the request is sent in relation to
the beacon period as shown in Figure 1. However, since the
TCP data packets destined for the mobile device are delayed
until the beginning of a beacon period, the mobile device al-
ways responds with TCP ACK packets immediately after the
beacon and the TCP connection becomes synchronized with
the PSM-static beacon period. Thus, the observed RTTs are
rounded up to the nearest 100 ms. Figure 2 shows the esti-
mated observed RTTs and slowdowns with PSM enabled.
The slowdown is greatest when the actual RTT is signifi-
cantly less than 100 ms.
As a TCP connection over a PSM-static link evolves, each
window of data takes 100 ms to transmit until enough data
is in transit to prevent the network interface from going into
sleep mode. At the beginning of a beacon period the amount
of data buffered at the AP is equal to the TCP window size
(assuming sufficient bandwidth between the server and the
AP). As soon as the mobile device wakes up and receives the
first TCP data packet, it sends an acknowledgment prompt-
ing the server to send more data. The new data arrives from
the server approximately one RTT (the actual server RTT, not
100 ms) after the start of the beacon period, during which
time the wireless link continually transmits data at the link
rate. If the AP finishes sending the buffered window of data
to the mobile device before the new data arrives from the
server, the mobile device will enter sleep mode until the next
beacon time. However, if the buffered window of data keeps
the wireless link busy until the new window of data begins to
arrive from the server, the network interface will stay awake
continuously and the power-saving mode will no longer de-
grade performance.
Thus, assuming sufficient bandwidth between the server
and the AP, the transmission of each TCP window takes
100 ms until the window size grows to the bandwidth-delay
product (the wireless link bandwidth multiplied by the ac-
tual server RTT) and one window can keep the wireless link
busy for an entire round trip time. For this to occur, the mo-
bile device’s advertised TCP window must be sufficiently
large. Additionally, enough buffering must be available at
the AP to store the window of data; otherwise, TCP packets
will be dropped and the connection will never be able to fully
saturate the wireless link.
2.3 Measured TCP Performance
Figure 3 shows the measured evolution of a TCP connec-
tion with and without PSM enabled. For this test, the mo-
bile client
1
opened a TCP connection with a server and sent a
request for 40 kBytes of data; the server responded with the
data. The network interface card (NIC) was rated at 11 Mbps,
although the maximum possible TCP data throughput was
less than this as shown in the results below. The server was
in the same building as the 802.11 access point and three net-
work hops away; the RTT was about 5 ms, and the band-
width between the server and AP was at least 10 Mbps. The
times at which data packets were sent from the server are
shown, where time zero is the time that the server saw the
initial SYN packet.
With PSM-static off, the connection quickly saturates
the available bandwidth of the network—the maximum is
around 6.4 Mbps, limited by the 802.11 wireless link. How-
ever, with PSM-static on, the initial RTTs are increased to
100 ms. With an actual RTT of 5 ms, only about 4000 bytes
of buffered data should be required to keep the 6.4 Mbps link
The mobile client used for all tests in this paper was a Com-
paq iPAQ H3600 series hand-held computer running Famil-
iar Linux version 0.4 with an Enterasys Networks Roam-
About 802.11 DS High Rate network interface card.
3
0 0.1 0.2 0.3 0.4
0
10
20
30
40
time (s)
sequence number (kB)
PSM off
PSM on
Figure 3: Measured evolution of a
TCP connection with and without
PSM enabled.
1B 8B 64B 1KB 8KB 64KB 1MB
10ms
100ms
1s
10s
transfer size
transfer time
5ms, 10Mbps, PSM off
5ms, 10Mbps, PSM on
80ms, 10Mbps, PSM off
80ms, 10Mbps, PSM on
50ms, 70Kbps, PSM off
50ms, 70Kbps, PSM on
Figure 4: Measured data transfer size
vs. transfer time for request/response
transactions over TCP with various
servers and PSM on and off. Both
axes use log scale.
1B 8B 64B 1KB 8KB 64KB 1MB
1
2
4
6
8
10
20
transfer size
PSM slowdown
5ms, 10Mbps
80ms, 10Mbps
50ms, 70Kbps
Figure 5: PSM slowdown from Fig-
ure 4. Both axes use log scale.
busy for long enough to allow the next window of data to be-
gin arriving from the server and prevent the network inter-
face from going to sleep. As shown in Figure 3, this happens
after the third 100 ms RTT when the TCP window grows to 4
packets (about 6000 bytes). Since this connection has a short
server RTT and small bandwidth-delay product, it is close to
the best-case scenario for PSM-static in terms of saturating
the link in the fewest number of 100 ms RTTs.
In another test of PSM-static, the mobile client opens a TCP
connection to a server and sends a request for some number
of bytes; the server responds by sending the requested block
of data. By doing this for power-of-two data transfer sizes
between 1 Byte and 4 MBytes, we determined the relation-
ship between data transfer size and transfer time. The client
used was the same iPAQ device. The server was run on var-
ious machines to evaluate different network characteristics.
The first server was in the same building and three network
hops away from the AP; the RTT was 5 ms, and the band-
width was at least 10 Mbps. The second server was located
around 3000 miles and 20 network hops away and had a high
bandwidth network path to the AP; the RTT was 80 ms and
the bandwidth was at least 10 Mbps. The third server was lo-
cated around 3 miles and 8 network hops away and behind
a DSL network connection; it had a 50 ms RTT and outgoing
bandwidth of 70 Kbps. Each performance test was run ten
times alternating between PSM on and PSM off (five tests
each). The results showed no significant variations between
runs, and the mean values are presented.
Figure 4 shows the total transfer time (including the re-
quest and response) as a function of data transfer size for
each server with both PSM on and PSM off. Figure 5 presents
another view of the same data; it shows the slowdown in-
curred using PSM. For small data transfer sizes the entire re-
sponse fits in one or two TCP data packets, and the total time
for the transaction is equal to two RTTs—during the first RTT
the client sends a SYN packet to the server, and the server re-
sponds with a SYN+ACK packet; during the second RTT the
client sends the request to the server and it responds with
up to two data packets. With PSM off, the transfer time is
determined by the RTT to each server; however, with PSM
on, the transfer times are 200 ms regardless of the server. The
observed slowdowns match those predicted by Figure 2.
The transfer times for the low-bandwidth (70 Kbps) server
become bandwidth-limited even before the transfer requires
more than one RTT. For the high-bandwidth servers, the
transfer times begin to take multiple RTTs as the data trans-
fer size increases and eventually become bandwidth-limited;
the maximum bandwidth achieved was about 4.9 Mbps.
With PSM on, the maximum bandwidth achieved was about
3.4 Mbps. Apparently, the maximum bandwidth is limited
by the overhead incurred by the PSM signaling; a close look
at Figure 3 reveals that the data packet spacing in steady state
is slightly higher with PSM on.
In some cases, the mobile device sends data to a remote
machine rather than vice-versa; for example, this occurs if a
mobile user is uploading a file, serving data in a peer-to-peer
application, running a Web server, etc. In this case, PSM-
static causes the TCP ACKs to be delayed instead of the data
packets. We ran the same performance test with the mobile
device configured as the server, and a machine on the 5 ms,
10 Mbps network configured as the client. The results were
essentially identical to those obtained when the mobile de-
vice was the client.
The main finding from these measurements is that the
100 ms sleep interval used in PSM-static is too coarse-grained
to maintain good performance, especially for short TCP data
transfers that are dominated by RTTs.
2.4 Performance Inversion
Somewhat paradoxically, TCP may achieve higher through-
put over a lower bandwidth PSM-static link, resulting in per-
formance inversion! As discussed in Section 2.2 and shown
in Figure 3, PSM-static causes the transmission of each TCP
window to take 100 ms until the window size grows to the
product of the wireless link bandwidth and the network RTT
delay between the mobile device and the server. Therefore,
a lower bandwidth PSM-static link will become saturated
sooner and prevent the network interface from entering sleep
mode. Figure 6 shows simulation data that demonstrates this
behavior.
2
The figure shows the transfer times versus the
wireless link bandwidth for various server RTTs, both with
and without PSM and for data transfers of 10 KBytes and
1 MByte. The AP to server bandwidth was set to 100 Mbps.
Figure 6 shows that a 1 Mbps wireless link is faster than
The simulation methodology is described in Section 5.1.
4
0 5 10 15 20
0
0.1
0.2
0.3
0.4
0.5
0.6
10 KB, PSM off
time (s)
0 5 10 15 20
0
2
4
6
8
10
1 MB, PSM off
80ms
40ms
20ms
10ms
0 5 10 15 20
0
0.1
0.2
0.3
0.4
0.5
0.6
10 KB, PSM on
bandwidth (Mbps)
time (s)
0 5 10 15 20
0
2
4
6
8
10
1 MB, PSM on
bandwidth (Mbps)
Figure 6: TCP request/response transfer times versus wire-
less link bandwidth for various server RTTs. The left
graphs represent a 10 KB data transfer, and the right graphs
represent a 1 MB data transfer. The upper graphs show
transfers with PSM off, and the lower graphs show trans-
fers with PSM on. Paradoxically, in some cases the transfer
times are shorter with a lower bandwidth PSM-static link.
higher bandwidth links for a 10 KB data transfer. With a
10 ms server RTT, the connection has a bandwidth-delay
product of 1,250 bytes (10,000 bits). Therefore, it becomes
saturated during the initial TCP round trips, and the PSM
stops putting the network interface into sleep mode; the re-
quest/response transaction takes just over 3 round trip times
(300 ms). For wireless link bandwidths greater than 3 Mbps,
or for server RTTs greater than 20 ms, the TCP window never
grows to the bandwidth-delay product (or does so only on
the last round-trip), and the request/response transaction al-
ways takes about 5 round trip times (500 ms).
The 1 MByte transfer size demonstrates an interesting in-
teraction between TCP and PSM-static. Whenever the re-
ceiver’s advertised maximum TCP window size is not large
enough to keep the wireless link busy for an entire RTT, the
throughput is limited to one maximum TCP window per
beacon period. For the simulations, the mobile device’s ad-
vertised window is 20 TCP packets (1,500 bytes each), or
about 240 kbits, and one maximum window per 100 ms bea-
con period is equivalent to 2.4 Mbps. The bandwidth-delay
product for a 20 ms server RTT crosses the 240 kbits threshold
when the wireless link bandwidth increases from 11 Mbps
to 12 Mbps, and for a 40 ms server RTT when the wireless
link bandwidth increases from 5 Mbps to 6 Mbps. Once they
cross this threshold, the transfer times increase sharply to
4.1 s, an average throughput of 2.05 Mbps. This shows an
unexpected, emergent interaction between TCP and PSM-
static. With long server RTTs, the receiver’s advertised TCP
window limits performance even with PSM off (e.g., the
throughput saturates at about 2.5 Mbps for an 80 ms server
RTT), but it does not lead to the performance inversion.
These results also demonstrate that, if PSM-static is used,
absolute performance may degrade if the wireless link band-
width increases (e.g., with 802.11a).
3. Client Network Usage Characteristics
In optimizing a network access protocol to minimize
power consumption, it is important to consider how clients
use the network. Since there is a trade-off between the extent
to which power consumption is minimized in sleep mode
and how long it takes to wake up (and also how much en-
ergy the transition takes) [1, 14], the sleep duration deter-
mines how low the power consumption can be. In addition,
waking up to listen to beacons consumes energy; the listen
interval determines the significance of this overhead.
To evaluate the characteristics of client network usage, we
analyzed client Web traffic from the UC Berkeley Home IP di-
alup service traces [8]. The network activity for these traces
is dominated by long transfer times over the slow modem
links, but certain aspects are relevant to general client usage
patterns. In particular, the time that clients spend idle (pre-
sumably due to user “think time”) or waiting for responses
from servers present opportunities for the network interface
to enter a sleep mode, and these times are probably not crit-
ically dependent on the bandwidth of the client’s network
link.
In analyzing the traces, we tracked each client’s state as
one of:
wait-for-server: the client has one or more out-
standing requests, but is not receiving any
responses
receive-response: the client is receiving one or
more responses
inactive: the client has no outstanding requests
and is not receiving any responses (this in-
cludes both user “think time” and browser
processing time)
Figure 7 shows the cumulative distribution function (CDF)
for the client wait-for-server times. The solid line shows the
percentage of wait-for-server events that last for less than a
given elapsed time. The dashed line shows the percentage
of the total wait-for-server time that is spent in these events.
For example, 88% of all wait-for-server events take less than
1 s, and these events account for 19% of the total time spent
in all wait-for-server events.
Figure 8 shows the CDF for the client inactive times. The
solid and dashed lines are as in Figure 7. However, in the
traces many clients have no activity over a period of several
days; if this data is included these inactive times completely
dominate the total inactive time (as shown by the dotted line
which is barely visible above the x-axis). Therefore, inactive
events longer than 1000 s (around 2% of all inactive events)
were excluded from the total inactive time represented by
the dashed line. The figure indicates that 26% of all inactive
events take less than 1 s, and these events account for 0.5% of
the total inactive time. If only inactive events less than 100 s
are included (versus 1000 s as shown in Figure 8), the inactive
events less than 1 s account for 1.1% of the total; and if only
inactive events less than 10 s are included, the inactive events
less than 1 s account for 6.8% of the total.
For completeness, Figure 9 shows the CDF for the client
receive-response times. Since the clients use slow modem
links, long transfer times are the norm. The prevalence of
receive-response times less than 0.1 s is presumably due to
responses that fit in one TCP packet.
The important point about these results is that although
most wait-for-server and inactive events are of short dura-
5
