A systematic Characterization of Application Sensitivity to Network Performance

77
SFS curve in the next section.
In order to understand the SFS curve, a more complex model of the NFS system is nec-
essary than the simple frequency-cost pairs used in the Split-C/AM and NPB models. We thus use
simple queuing theoretic models to understand the relationship between the networking parameters
and the SFS curve. As in previous chapters, our goal in this work is not to develop highly accurate
models. Rather, the purpose of the queuing model is to gain insight as to how a system should behave
as we change the networking parameters. The model’s value lies in its ability to identify why the sys-
tem responds as it does. The quote at the beginning of this chapter illustrates this same purpose of
analytic models in the field of economics.
The combined use of a model and experimental data forms a synergy which is much more
powerful than either alone. With only a model, we can predict the responses but the results are sus-
pect. Measured data alone, while not suffering from lack of credibility, often lacks the simple con-
ceptual interpretations that models provide. Using both a model and measurement we can explain
the measured results in terms of the model. Points where the data deviates from model predictions
expose weaknesses in our understanding of the system.
A side benefit of our choice of workload, SPECsfs, is that it allows us to compare our re-
sults to industry published data. More importantly, using the techniques in this work we can infer
the structure of the NFS servers from the data published by SPEC.
The remainder of the chapter is organized as follows. We first describe the details of the
apparatus relevant to NFS servers in Section 5.1. Section 5.2 provides background on SPECsfs, the
workload for this chapter. Next, Section 5.3 introduces our simple queuing-theoretic model of an
NFS system. Section 5.4 documents previous work on NFS. Next, Section 5.5 documents the mea-
sured sensitivities to network parameters on two live systems and describes the accuracy of the pre-
dictions made by the model. Section 5.6 summarizes some implications of our results, and analyzes
industrial data in the context of our methods.
5.1
Experimental Setup
This section introduces the experimental set-up used in our NFS experiments. We focus
on the disk sub-system because this is the component of interest unique to NFS performance. Recall
that the networking apparatus used to control the LogGP parameters was described in detail Sec-
tion 2.3.3. This section first describes the general characteristics of the clients, followed by a more
detailed description of the two different servers.

---

78
As in the Split-C/AM and NPB experiments, all of the machines in our experiments consist
of Sun Ultra-1 workstations. Attached to the S-Bus is an internal narrow SCSI bus and local disk that
holds the operating system and swap space. All the clients have 128 MB of main memory. We use
a total of 4 clients: 3 load-generators and 1 master control station. The control station and other
machines are also connected via a switched 10Mb/s Ethernet. The Ethernet is used to start and stop
the benchmark as well as monitor results.
The primary difference between our two servers is the disk sub-system. The “SCSI” sys-
tem contains 128MB of main memory and 24 7200 RPM 9GB IBM drives. The drives are evenly
divided between two SCSI buses. The S-bus interfaces used are the fast-wide Sun ‘’FAS” controller
cards. In contrast, the “RAID” system contains 448 MB of main memory. The 28 7200 RPM 9GB
Seagate disks are contained in a Sun “A3000” RAID. The disks are divided into 5 RAID level-0
(striping) groups; 4 groups have 6 disks and the last group contains 4 disks. The striping size is 64
KB. The A3000 contains 64 MB of battery-backed NVRAM which can absorb some writes that may
otherwise have gone to disk.
There are two reasons for investigating different systems. First, they allow us to draw
conclusions about the effects of different hardware and software, e.g., drivers, main memory, and
NVRAM. Second, having two systems serves as a check on our model; inaccuracies may show in
one system but not the other. In addition, the RAID is closer in spirit to servers found in published
SPEC data.
5.2
SPECsfs Characteristics
Just as we did with the Split-C/AM and the NPB, in this section we first characterize the
SPECsfs benchmark which forms the workload for this chapter. We then describe the similarities
and differences between this and previous work done to quantify NFS performance.
SPEC, while widely known for its CPU benchmarks, also produces an NFS benchmark,
SPECsfs (formerly known as LADDIS) [107]. SPEC released the latest version, SFS 2.0, in 1997 [94].
Version 2.0 adds several enhancements. First is the addition of version 3 of the NFS protocol [82] as
well as retaining NFS version 2. In addition, TCP can be used as a transport layer instead of UDP.
The combination of these two variants results in four possible configurations (e.g., NFS version 3
on UDP and NFS version 2 on TCP). We focus on NFS version 2 running over UDP because this
will comprise a large number of installed systems. Unless otherwise reported, all results are for sys-
tems running SFS 2.0, NFS version 2 using UDP. We do examine some TCP vs. UDP tradeoffs in

---

79
Response Time
Saturation
Slope
Base
NFS Operations/Second
Figure 5.1: Important Characteristics of the SFS Curve
This figure shows the important characteristics of all SFS curves: the base (i.e. minimum) response
time, the slope, which determines the rate of increase in response time as load increases for a linear
region of the curve, and the saturation point at the peak operations sustainable.
Section 5.5.2.
SPECsfs, as a synthetic benchmark, must define both the operation mix and scaling rules.
The mix has been derived from much observation of production systems [94, 107]. SFS 2.0 uses a
significantly different mix from SFS 1.0. With the decline of diskless workstations it was found that
the percentage of writes had also steadily declined. Qualitatively, the SFS 2.0 operation mix is mostly
small metadata operations and reads, followed by writes. The mix represents a challenge to latency
tolerating techniques because of the small and synchronous nature of most operations. The two most
common operations are
get attributes
and
directory lookup
; combined they make up
62% of the SFS 2.0 workload. Reads comprise 14% and writes comprise 7% of the operations with
other metadata operations making up the remainder.
Learning from past benchmarking errors, SPECsfs also defines scaling rules for the data
set. In order for a vendor to report a large number of operations per second, the server must also
handle a large data-set. For every NFS op/sec, the clients create an aggregate of 10 MB of data. The
amount of data accessed similarly increases; for each op/sec 1 MB of data is touched.
Unlike the SPEC CPU benchmarks which report point-values, SPECsfs reports a curve
of response time vs. throughput. The reported response time is the weighted average of different
operations’ response times, where the weights are determined by the percentage of each operation
in the mix. Figure 5.1 shows an abstract SFS results curve. The signature of the curve contains three
key features: the base response time, the slope of the curve in the primary operating regime, and the
saturation point.
At low throughput there will be an average base minimum response time. The base rep-

---