A systematic Characterization of Application Sensitivity to Network Performance

43
a direct measurement of the change in
®
as a function of the hitbox operations.
2.6.4
Hall
The impact of specific networking technologies (ATM, Autonet, FDDI) on NFS was ex-
amined in [49]. This study used an application-centric, direct measurement methodology. They used
two workloads. The first was NFSstone [93], the precursor to SPECsfs. Some of their most inter-
esting data, however, came from the direct measurements of a 200 workstation production system
serving about 150 people.
The methodology of measurements of a production system differ sharply from majority of
previous work, and in some sense is also the most representative. For example, if real systems do not
behave like poisson processes, this will be captured in production system. The study found that the
observed RTT in productions systems had a much larger variance in comparison to their controlled
experiments.
Their conclusions are quite similar to ours: CPU overhead is a dominant factor in NFS
performance. One of the targets of the study was the effects of overhead reduction by increasing the
Maximum Transmission Unit (MTU) size. The study found that reducing overhead by increasing
MTU size can greatly impact performance. However, the data shows the relationship is non-linear.
Increasing the MTU from the 1.5 KB Ethernet MTU to the 4.3 KB FDDI MTU resulted in a large
improvement in the average response time for a mix of NFS operations. However, the improvement
from a 4.3 KB MTU to the 9 KB ATM MTU was much less, and in some cases actually degraded
performance. Unfortunately, they did not present the operation mix for their live experiments.
It is important to note that interpretation of the results in the original work was not cast in
term of overhead. Rather, the work discussed “end-system” performance:
... in order to achieve maximum benefit from modern and fast networks in the future
a big effort must be addressed towards the improvement of the end systems.
This quote highlights the importance of simple models, such as LogGP, in understanding
machine performance. Without a simple model, characterizing complex systems in meaningful ways
is difficult task. For example, the Hall study provided detailed breakdowns of different pieces of the
NFS operations, but did not lump them into the categories of overhead and latency. Although easy to
discern the difference from their data, such simple categorization would have made explaining their
results much more intuitive.

---

44
Degree of
realism
Experimental perspective
Network
Application
Simulation Emulation Direct
Measurement
Analytic
Modeling
Martin
Holt
Hall
Chang
Anh
Chiu
Huang
Wilson
Figure 2.8: Methodologies in Context
This figure shows were various works fit in the space of network experiment methodologies. The x-
axis orders methodologies by degrees of realism, while the y-axis shows the focus of the dependent
variable.
2.6.5
Summary
In this section, we return to the network experiment conceptual framework developed in
Section 1.1. Figure 2.8 shows a number of studies placed in our framework of experiment design.
The experiments are: Holt [52], Martin [73], Hall [49], Chang [21], Ahn [1], Chiu [24], Huang [54]
and Wilson [62, 66, 67]. When placing experiments in this space, we have used the primary focus
of the study to determine the axis. Although some studies [1, 52, 73] used multiple techniques at
once, it is interesting that even these have one axis clearly dominate the other.
We can see that experiments cover nearly the full spectrum of experiment design. A point
relevant to this thesis is that there are few experiments which categorize application-centric sensitiv-
ities to abstract parameters. Thus, there is little systematic exploration of the system design space.
Instead, most studies compare single instances of different systems or algorithms, e.g. TCP Vegas
vs. Reno [1], credit vs. rate based flow control [21], or congestion avoidance algorithms [24]. A
point which does not need elaboration is that, of course, many research groups have an axe to grind
with regard to these systems.
There is a notable lack of application-centric experiments which rely on analytic model-
ing. Although [24], and to a lesser extent [56] model the effects on applications somewhat, the ac-
tual concern is not applications per say, but the collective effects of many applications on the net-
work infrastructure. Speculating a bit, the author believes this is because applications are difficult

---

45
to model. Indeed, only recently has the network community accepted the work in [66]; that poisson
processes are an inaccurate model for aggregating application traffic. It is clear from our examina-
tion of the literature that application behavior has not received the same attention in the network or
parallel program communities as in the architecture or database communities. The adoption of well
defined benchmark suites would go a long way towards solving this problem.

---

46
Chapter 3
Split-C/AM Program Sensitivity
An experimental science is supposed to do experiments that find generalities. It’s not
just supposed to tally up a long list of individual cases and their unique life histories.
That’s butterfly collecting. — Richard C. Lewontin, The Chronicle of Higher Education,
February 14, 1997
This chapter contains an examination of the sensitivities of a suite of parallel programs
written in the Split-C language or programmed in Active Messages directly. We first characterize
the programs in terms of Split-C operations and parallel program orchestration techniques. We then
describe the programs in detail, followed by some simple analytic models of them. Next, we present
the results of our sensitivity experiments and comment on the accuracy of the analytic models. Fi-
nally, we summarize the results of this chapter.
3.1
Characterization
With a methodology in place for varying communication characteristics, we now charac-
terize the architectural requirements of the Split-C application suite. Split-C is a parallel extension of
the C programming language that provides a global address space on distributed memory machines.
Split-C (version 961015) is based on GCC (version 2.6.3) and Generic Active Messages (version
961015), which is the base communication layer throughout. Note that two of the programs use Ac-
tive Messages directly, bypassing the Split-C layer. Although the programming model does not pro-
vide automatic replication with cache coherence, a number of the applications perform application-
specific software caching. The language has been ported to many platforms [2, 72, 103, 104]. The
sources for the applications, compiler, and communication layer can be obtained from a publicly

---