A systematic Characterization of Application Sensitivity to Network Performance

---

ix
List of Tables
2.1
Baseline LogGP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.2
Calibration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.1
Split-C Applications and Data Sets
. . . . . . . . . . . . . . . . . . . . . . . .
47
3.2
Split-C Communication Summary . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.3
Predicted vs. Measured Run Times Varying Overhead . . . . . . . . . . . . . .
57
3.4
Predicted vs. measured run times varying gap . . . . . . . . . . . . . . . . . .
60
4.1
NPB Communication Summary . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.2
NPB Predicted vs. Measured Run Times Varying Overhead . . . . . . . . . . .
70
4.3
NPB Predicted vs. Measured Run Times Varying Bulk Gap . . . . . . . . . . .
74
5.1
SPECsfs Linear Regression Models & Accuracy . . . . . . . . . . . . . . . . .
83
6.1
GAM Pipeline Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2
SPINE LogGP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
A.1 SPECsfs97 Disclosure: SCSI Performance . . . . . . . . . . . . . . . . . . . . 130
A.2 SPECsfs97 Disclosure: SCSI Server and Network . . . . . . . . . . . . . . . . 130
A.3 SPECsfs97 Disclosure: SCSI Load Generators . . . . . . . . . . . . . . . . . . 131
A.4 SPECsfs97 Disclosure: SCSI Testbed Configuration . . . . . . . . . . . . . . . 131
A.5 SPECsfs97 Disclosure: RAID Performance . . . . . . . . . . . . . . . . . . . . 131
A.6 SPECsfs97 Disclosure: RAID Server and Network
. . . . . . . . . . . . . . . 132
A.7 SPECsfs97 Disclosure: RAID Load Generators . . . . . . . . . . . . . . . . . . 132
A.8 SPECsfs97 Disclosure: RAID Testbed Configuration . . . . . . . . . . . . . . . 133
B.1 Split-C/AM Run Times varying Overhead on 16 nodes . . . . . . . . . . . . . . 135
B.2 Split-C/AM Run Times varying Overhead on 32 nodes . . . . . . . . . . . . . . 135
B.3 Split-C/AM Run Times varying gap . . . . . . . . . . . . . . . . . . . . . . . . 135
B.4 Split-C/AM Run Times varying Latency
. . . . . . . . . . . . . . . . . . . . . 136
B.5 Split-C/AM Run Times varying Bandwidth . . . . . . . . . . . . . . . . . . . . 136
B.6 NPB Run Times varying Overhead
. . . . . . . . . . . . . . . . . . . . . . . . 136
B.7 NPB Run Times varying gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.8 NPB Run Times varying latency . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.9 NPB Run Times varying Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 137

---

x
B.10 SPECsfs Response Times in varying Latency on the SCSI system . . . . . . . . 138
B.11 SPECsfs Response Times varying Latency on the RAID system . . . . . . . . . 139
B.12 SPECsfs Response Times varying Overhead on the RAID
. . . . . . . . . . . 140
B.13 SPECsfs Response Times varying Overhead on the SCSI system . . . . . . . . 141
B.14 SPECsfs Response Times varying Bandwidth on the SCSI system
. . . . . . . 142

---

1
Chapter 1
Introduction
Nature is so complex and random that it can only be approached with a systematic
tool that presupposes certain facts about it. Without such a pattern it would be impossi-
ble to find an answer to questions even as simple as ‘What am I looking at?’ — James
Burke, The Day the Universe Changed.
In recent years networking infrastructure and applications have experienced rapid growth.
In the System Area Network (SAN) context designs are quite diverse, spanning a range of both hard-
ware [16, 17, 23, 47, 53] as well as specialized system software [72, 81, 88, 103]. Local Area Net-
works (LANs) have also made impressive improvements, advancing from shared 10 Megabit (Mb)
designs, to 100 and 155 Mb designs [15, 33], to switched gigabit designs [98, 99]. Wide Area Net-
works (WANs) are also experiencing equally dynamic growth: emerging systems include packet ra-
dio, Integrated Services Digital Network (ISDN), Cable Modems, Asymmetric Digital Subscriber
Loop (ADSL) and Direct Broadcast Satellite (DBS). On the applications side, there are many new
applications spanning these domains, such as protocol validators and network infrastructure services
[41, 97].
The explosion of designs in networking technologies and applications has resulted in an in-
creased demand for a systematic, quantitative framework in which to reason about performance. His-
torically, networking hardware and system software are evaluated using micro-benchmarks. Tools
such as ttcp [22], lmbench [74], and netperf [58] provide the two most commonly used micro-bench-
marks: Round Trip Time (RTT) and peak bandwidth (PB). Indeed, the evaluation of many designs [16,
33, 103] often only reports these two metrics. A third common metric is bandwidth as a function of
transfer size. However, even this additional metric tells us very little about the underlying commu-
nication sub-system. Like the MIPS of CPU performance, micro-benchmarks in isolation provide

---

2
little insight as to how improvements in networks improve application performance.
The exponential growth in CPU performance illustrates the benefit of a good conceptual
framework that captures the essential performance tradeoffs of a system. An enormous improvement
over the simple MIPS micro-benchmark was the “iron triangle”.
1
Although conceptually simple,
the iron triangle model of application execution captures the essence of many performance tradeoffs
without drowning in details. It gave a diverse community of application developers, compiler writers
and computer architects a common framework in which to reason about the performance impact of
different designs. The model thus allowed quantitative comparisons of processor designs using real
programs. Indeed, a consistent theme across a variety of computer systems areas has been that the
metrics and conceptual models used in evaluation are as important, if not more so, than the designs
themselves.
This work uses an existing model, LogGP [2, 29], as a generalized framework for under-
standing application performance as it relates to the network hardware/software combination. The
parameters of the model: latency, overhead, gap and peak bandwidth for large transfers, correspond
well to the networking hardware and software components of real machines. An important feature of
the LogGP model is that it allows application developers and machine designers to reason about the
overlap between communication and computation. Thus, algorithms and applications can be charac-
terized as to their degree of latency tolerance. The RTT and peak bandwidth metrics bundle overhead
and latency into single parameters; characterizing an application’s tolerance to latency as distinct
from overhead is impossible with those parameters alone. In addition, RTT and PB fail to capture im-
portant characteristics of distributed systems, which transfer “medium” sized data (in the single KB
range) [106]. Although there are other algorithmic models in the literature [18, 43, 46, 101] which
can capture some aspects of the network, they have been developed for parallel program design and
so do not correspond well to machine components. Evaluating the components of the networking
system as they relate to the application is easier with the LogGP model.
Once we have a firm grounding in a model, we can begin to make quantitative claims about
networked computer systems in the language of the model, in our case LogGP. This thesis provides
such a systematic study of the LogGP parameter space. Our aim is to investigate the impact of com-
munication performance on real applications. Furthermore, we want to understand which aspects
of communication performance are most important. We begin our investigation by quantifying the
sensitivity of applications to the parameters of the LogGP model. We define sensitivity as some ap-
 
The iron triangle is the model: CPU time = Instruction Count
¡
Cycles per Instruction
¡
Cycle Time.

---