A systematic Characterization of Application Sensitivity to Network Performance

12
important advantage of our method over traditional ones is that we can categorize the shape of the
slowdown curve because our apparatus allows us to observe plateaus or other discontinuities. These
discontinuities are of prime importance to the system architect because designs can take advantage
of performance plateaus.
We find that our application-centric, emulation approach works well in practice. However,
care must be taken to calibrate the apparatus, as well as cross-check the results against simple models.
We are able to quantify the sensitivity curves of many different applications in a variety of program-
ming domains, including parallel computing and distributed file systems. Our apparatus scales over
an order of magnitude in overhead, latency and bandwidth. We can thus emulate networks ranging
from high-performance SANs, to traditional LANs, and even WAN links.
1.2.2
Application Behavior
A unique approach of this thesis is the use of live systems in a bottleneck-style of anal-
ysis, as opposed to the more traditional approaches using analytic models. We find that a modern
computer system is complex enough that our approach is a valid method of simply characterizing
the application space.
The use of a live system allows us to observe and quantify real application behavior and
validate models. Modeling results are always suspect until validated by other means. Although mea-
surement as a technique can certainly quantify application behavior, using measurement alone it is
difficult to obtain, without factor analysis, the sensitivity results provided for by our method.
We can obtain answers to a broad range of questions about application behavior using the
methods in this thesis. The sensitivities to
¤
,
¥
,
¦
, and
§
are the most obvious. However, we can also
ask questions such as is communication bursty, or uniform? Do applications contain many serial
dependencies? If so, does the nature of these dependencies result in more sensitivity to overhead or
latency? We can also begin to explore questions such as if we can we restructure the application to
better suit modern machine characteristics. If we observe enough applications, we can also hope to
make some generalizations about how programmers use these systems.
We find that programmers employ a diverse set of latency tolerating techniques and that
these are quite effective in practice. However, many of these techniques are still sensitive to over-
head. Thus, many applications demonstrated the strongest sensitivity to software overhead. For both
a range of parallel programs and NFS, overhead is a limiting factor. Continued improvements in
software overhead will yield the largest benefits. Applications also demonstrated strong sensitivity

---

13
to various bandwidths, suggesting that communication phases are bursty and limited by the rate at
which messages or bytes can be injected into the network. Examining the history of many programs,
we see that program optimizations shift sensitivity away from latency and overhead and towards
bandwidth.
1.2.3
Network Architecture
Armed with the sensitivity results and the LogGP model, we can answer a number of im-
portant architectural questions. For example, how much do network design changes affect appli-
cation performance? How does increasing network performance improve application performance?
Would additional hardware support be worth the costs? If so, what architectural features would yield
the largest benefit?
LogGP plays a key role in our ability to answer these architectural questions because the
parameters of the model were designed to correspond to real machine components. The LogGP
model has been validated as an architectural model, as well as a parallel programming model, on
a wide variety of real machines and message layers [31, 55]. We can thus draw strong conclusions
about how improvements in machines will affect application performance based on our abstract sen-
sitivity results. For example, if we improved the networking code by a factor of 2, and if our sensi-
tivity models for
¨
have a slope of 1 (i.e. each factor of
¨
improves performance by 1 unit) then we
can have reasonable confidence that our improved networking code would result in an overall
©
performance improvement.
Our result that applications demonstrate the strongest sensitivity to software overhead im-
plies that continued improvements in software overhead will yield the largest benefits. Hardware and
software should be designed to minimize software overhead, perhaps even at the expense of some
of the other parameters. In particular, our results show the somewhat counter intuitive result that ar-
chitectures that minimize overhead at the expense of network latency can deliver increased overall
performance for most applications.
Applications also demonstrated strong sensitivity to various bandwidths. Although many
designs can deliver near peak per-byte bandwidths for long messages, we also measured a number of
applications where small message throughput was nearly as important. Architectures must deliver
not only low overheads, but also should deliver close to the peak bandwidth for small messages. As
with overhead, our results on application behavior show that architectures that can sustain a high per-
message rate for small messages at the expense of latency can still maintain good overall application

---

14
performance.
Chapter 6 explores a novel architectural designs based on the results of this thesis. We
use SPINE [40], a software infrastructure, to examine the effect of overhead reduction by adding
computation into the network device. The results, while encouraging, show that our understanding
of overhead reduction techniques is still quite limited and more investigation in this area is warranted.
We show that more radical software and hardware architectures will be needed to deliver order of
magnitude performance improvements to applications while maintaining connectivity to standard
protocols.
1.2.4
Modeling
Because we use analytic modeling to validate the results of our live system experiments,
we can ask questions about the models themselves. For example, how well do simple models
4
predict
application run time? How accurate are simple models compared to live systems? If they are not
sufficient, how closely do fully characterized applications (e.g. those in [39]) match the known data?
Our simple models are by definition linear in event frequency and cost. If the measured
sensitivities are linear to the parameters simple models may be sufficient. More complex charac-
terizations such as those in [39] consider dependencies between communication events. A recent
complex variant of the LogP model [43] considers queuing effects due to endpoint congestion. For
this work we will use simple models wherever possible. We find that simple models can capture the
high-level impact of changing network performance, particularly for overhead, but more complex
models are needed when good fidelity is required.
We use a basic queuing theory to model NFS. While simple models may be useful in this
case, servers traditionally have been described using queuing theoretic models. Our apparatus allows
us to compare measured results against this class of traditional models. We find that queuing theory is
able to capture much of the behavior of an NFS system. However, at high loads the feedback control
loops in NFS cause the measured values to diverge from the models substantially.
1.3
Thesis Organization
The rest of this thesis is organized as follows. Chapter 2 describes the methodology in
detail. We describe our basic apparatus. We first background the basic communication software

We define a simple model to be one were the execution time is a linear function of a series of

event types where
each type has a frequency

, and cost

. Thus, total execution time =
! 
#"%$
&'

---