A systematic Characterization of Application Sensitivity to Network Performance

61
0
1
2
3
4
5
6
7
8
9
0
20
40
60
80
100
120
140
Slowdown
H
Latency
EM3D(r)
Barnes
P-Ray
EM3D(w)
Radix
Sample
Murphi
Connect
NOWsort
Radb
Figure 3.4: Sensitivity to Latency
This figure plots slowdown as a function of latency in microseconds. Latency is scaled by a factor of
20, ranging from SAN class latencies to a network built out of several long latency ATM switches.
The figure shows the effectiveness of a wide range of practical latency tolerating techniques.
The sensitivity of EM3D(read), Barnes, P-Ray, and Connect to latency results from these
applications’ high frequency of read operations (see Figure 3.2). Read operations require network
round-trips, making them the most sensitive to added latency. However, for all but one of these ap-
plications, the observed slowdowns are modest (at most a factor of four in the worst-case) even at
the latencies of store-and-forward networks (100
e
s).
EM3D(read) performs a large number of blocking reads; it represents a “worst-case” ap-
plication from a latency perspective because it does nothing to tolerate latency. It is also the only
application for which a simple model of latency is accurate. Interestingly, for equal amounts of
added “work” per message (100
e
s of latency and 50
e
s of overhead), the simple latency model
for EM3D(read) is quite accurate yet the simple overhead model under predicts the run time.
The applications which do not employ read operations largely ignore added latency. The
small decrease in performance at the tail of the slowdown curves is caused by the increase in gap
associated with large latencies as the Active Message flow control mechanism limits the network
capacity (see Table 2.2).

---

62
0
0.5
1
1.5
2
2.5
3
0
5
10
15
20
25
30
35
40
Slowdown

MB/s
Radb
NOWsort
P-ray
Barnes
Radix
Murphi
EM3D(w)
EM3D(r)
Sample
Connect
0
0.5
1
1.5
2
2.5
3
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
Slowdown

Gap (usec/byte)
Radb
NOWsort
P-ray
Barnes
Radix
Murphi
EM3D(w)
EM3D(r)
Sample
Connect
(a)
(b)
Figure 3.5: Sensitivity to Bulk Gap
This figure plots slowdown as a function of maximum available network bandwidth (a) as well as bulk
Gap (b). Bandwidth is scaled from 10 Mb Ethernet speeds to SAN speeds of near 30 MB/s. Although
bandwidth is a more intuitive measure, it is difficult to visualize the sensitivity to bandwidth from
figure (a) because as we scale
f
in a linear manner we are plotting a
g
h
bandwidth curve. Figure
(b) shows some applications slow down in a linear fashion as we scale
f
linearly.
3.3.4
Bulk Gap
Only applications attempting to send large amounts of data in bursts should be affected by
reductions in bulk transfer bandwidth. Note that we do not slow down transmission of small mes-
sages, but rather add a delay corresponding to the size of the message for each bulk message. Further,
applications should tolerate decreases in available bulk bandwidth until the bandwidth dips below
the application’s requirements at any point during its execution.
Figure 3.5(a) plots application slowdown as a function of the maximum available bulk
transfer bandwidth, a more intuitive measure than Gap. We also plot the same sensitivity to Gap
in Figure 3.5(b) in order to show the linear relationship between slowdown and
f
. Overall, the ap-
plications in our suite do not display strong sensitivity to bandwidth. No application slows by more
than a factor of three even when bulk bandwidth is reduced to 1 MB/s. Further, all of the appli-
cations, including Radb, which moves all of its data in a single burst using bulk messages, do not
display sensitivity until bulk bandwidth is reduced to 15 MB/s. Surprisingly, the NOW-sort is also
insensitive to reduced bandwidth. This version of the NOW-sort uses two disks per node. Each disk

---

63
can deliver 5.5 MB/s of bandwidth [8], and during the communication phase a single disk is used for
reading and the other for writing. As Figure 3.5 shows, NOW-sort is disk limited. Until the network
bandwidth drops below that of a single disk, NOW-sort is unaffected by decreased bandwidth.
3.4
Summary
Varying the LogGP parameters for our network of workstations and benchmark suite led
to a number of interesting results. We organize these around our four areas of contributions.
3.4.1
Performance Analysis
In the performance analysis area, we find that our apparatus was quite effective in mea-
suring the sensitivities of the Split-C/AM suite. Running real programs on the apparatus was not
a problem. All the programs were well behaved, giving consistent results from run to run. Even
Barnes, which would go into live-lock as we scaled overhead, exhibited this behavior in a repeat-
able way.
We were able to observe a number of effects that would be difficult to observe using other
techniques. These include a hyper-sensitivity to overhead from a number of applications. In addi-
tion, we were able to observe live-lock effects for Barnes which would require fairly sophisticated
models or simulators to observe. Our apparatus also allows us to quantify the point in the overhead
space where this effect occurs.
3.4.2
Application Behavior
In the behavior area, we find that applications displayed the strongest sensitivity to net-
work overhead, slowing down by as much as a factor of 50 when overhead is increased to roughly
100
i
s. Even lightly communicating processes suffer a factor of 3-5 slowdown when the overhead is
increased to values comparable to many existing LAN communication stacks. Frequently commu-
nicating applications also display strong sensitivity to gap suggesting that the communication phases
are bursty and limited by the rate at which messages can be injected into the network.
The effect of added latency and bulk gap is qualitatively different from the effect of added
overhead and gap. For example, applications which do not perform synchronization or read oper-
ations (both of which require round trip network messages) can largely ignore added latency. For

---