A systematic Characterization of Application Sensitivity to Network Performance

89
0
5
10
15
20
25
30
35
40
45
0
500
1000
1500
2000
2500
3000
3500
4000
Response Time (msec)
Î
Latency (usec)
SCSI
Ops/sec
200
400
600
800
0
5
10
15
20
0
200
400
600
800
1000
Response Time (msec)
Î
Latency (usec)
SCSI
Ops/sec
200
400
600
800
(a)
(b)
Figure 5.5: SPECsfs Latency vs. Response Time
This figure plots response time as a function of latency in microseconds. Measurements were taken
on the SCSI system. The graph on the left shows a range of
Ô
up to 4000
Õ
s. The graph on the right
shows that up to 150
Õ
s there is little sensitivity to
Ô
.
Õ
s of added
Ô
between 150 - 4000
Õ
s. This is quite a bit higher than the 2 predicted by the model in
Section 5.3.2. Figure 5.5(b) shows a completely insensitive region between 10 and 150
Õ
s.
An important result is that in the sensitive region, all the sensitivity curves are a constant 3
across an order magnitude change in
Ô
. Given that the system is responding in a linear fashion, there
may be an accurate way to model it. However, the constant of 3 is quite a bit higher than the constant
2 predicted by our simple model. A more complex model is needed to account for the discrepancy.
In the insensitive region we can see there is little, if any, measurable change in response
time as we vary
Ô
. For the same range of
Ô
, the same results applies to the RAID as well. This has
important implications for switch and interface designers as these operate in the 10’s of
Õ
s region.
From an NFS perspective, a LAN switch adding 10
Õ
s of delay per hop would be quite acceptable.
5.5.2
High Latency
The original NFS protocol was not designed to operate in environments with very high
Ô
.
NFS version 3 added several latency tolerating techniques, most notably asynchronous writes [82].
In this section, we examine the effects of very high
Ô
, in the 10’s of millisecond range. For example,
WANs typically have an
Ô
ranging from 10’s to 100’s of milliseconds.

---

90
0
20
40
60
80
100
120
140
160
200
400
600
800
1000
1200
1400
1600
response time(msec)
OPs/sec
NFS version 2
baseline
L=10ms
L=20ms
L=40ms
0
50
100
150
200
250
300
0
100
200
300
400
500
600
Response Time(msec)
Î
NFS V3 OPs/sec
NFS version 3
baseline
L=10ms
L=20ms
L=40ms
(a)
(b)
Figure 5.6: Effects of Very Long Latency
This figure plots the SFS curves as a function of very high latencies on the RAID. Measurements
for the graph on the left were taken on for NFS Version 2 over UDP, while measurements for the
graph on the right were taken using NFS Version 3 running over TCP. The figure is designed to show
the relative performance degradation for each version as neither the operations/sec or the response
times between versions is comparable.
Figure 5.6 compares the relative effectiveness of NFS version 2 running on UDP, a typical
configuration, to version 3 running on TCP for networks with high
Ö
. The experiment varies both
the NFS version and network transport at once to better understand the total impact of an upgrade.
Typically, operating systems that ship with version 3 also allow TCP as a transport layer. Both the
throughput and response times between NFS version 2 and version 3 are not comparable; thus we
examine the percentage of performance loss as we scale
Ö
.
Figure 5.6(a) shows, as expected, that the “classic” NFS V2/UDP performance over WAN
latencies is dismal. First, the base response time is hyper-sensitivity to high latency in that it is much
greater than one would predict from the simple model. Second, very little of the peak load is obtain-
able. NFS Version 3 over TCP is able to handle long latencies much better than version 2 over UDP.
Figure 5.6(b) shows that even at an
Ö
of 40 msec (a round trip of 80 msec), Version 3/TCP can sustain
50% of the peak throughput without adding extra clients.
A notable effect on both versions is that average response time decreases as the load in-
creases. This could be caused by a number of effects. One possible effect could be the interaction
of a light workload with the RPC and TCP transport protocols. These algorithms constantly probe

---

91
0
10
20
30
40
50
0
200
400
600
800
1000
Response Time (msec)
Î
NFS OPs/Sec
SCSI
O(usec)
80
105
130
180
280
480
580
0
10
20
30
40
50
60
70
80
90
100
200
400
600
800
1000
1200
1400
1600
Response Time(msec)
Î
NFS Ops/sec
RAID
O(usec)
80
85
90
95
100
105
130
180
280
(a)
(b)
Figure 5.7: SPECsfs Sensitivity to Overhead
This figure plots the SFS curves as a function of overhead in microseconds. Measurements for the
graph on the left were taken on the SCSI system, while measurements for the graph on the right were
taken on the RAID system.
the network looking for more bandwidth. Under a light workload however, an insufficient number
of packets may be sent for the protocol to reach a stabilization point in its time-out/re-try algorithm.
As both curves are consistent with this theory, it begs the question as to the performance of these
algorithms [56] under a very light load.
5.5.3
Overhead
Software overhead, the orphan of networking analysis, permeates the design space because
it affects all aspects of the SFS signature curve. We focus our analysis efforts, however, on its effect
on the saturation point. Not only are these effects likely to be the most pronounced, but they also
will greatly impact the machine size needed to sustain high loads.
Response to Overhead
Figure 5.7 shows the SPECsfs curves for both the SCSI and RAID systems while scaling
overhead from a baseline of 80
×
s. For the SCSI system we have truncated the results at the saturation
point to make the graph more readable.
Figure 5.7 shows that the base response time increases as we scale
Ø
, and the measured

---