A systematic Characterization of Application Sensitivity to Network Performance

95
0
10
20
30
40
50
0
200
400
600
800
1000
Response time (msec)
å
NFS Ops/Sec
SCSI
MB/s (1/G)
25.9
14.5
11.2
9.1
5.8
2.5
1.2
Figure 5.10: Sensitivity to Gap
This figure plots the SFS curves as a function of Gap in microseconds. Measurements for the graph
were taken on the SCSI system.
sitivity to
æ
is thus lower than what one might expect in a production environment. We explore the
implications of bursty networks to the sensitivity of
æ
in more detail in Chapter 5.6.
Figure 5.10 shows queuing delays at very low bandwidths that are not captured by the
model. There is a slight increase in slope at a bandwidth of 2.5 MB, and at 10 Mb Ethernet speeds
(1.2 MB/s) there is a noticeable increase in slope. Replacing the simple delay center with a more
sophisticated queuing network would capture these effects. However, given the low bandwidths at
which these effects occur, we have made a quite reasonable tradeoff between model simplicity and
accuracy.
5.6
NFS Summary
In this section, we describe the implications of our sensitivity results. As in previous chap-
ters, we organize our results around the four areas of performance analysis, application behavior,
architecture and modeling.

---

96
5.6.1
Performance Analysis
This chapter demonstrates that the TCP/IP apparatus is quite effective at adding control-
lable delays to various system components. One apparent drawback of our apparatus is that we could
not reduce overhead to low levels. It would thus appear that our apparatus is limited in its ability to
answer questions in the regime of low overhead. However, our methodology can overcome this limi-
tation. Rather than answer the question “what is the benefit of reduced overhead?” by measuring the
effects of low overhead directly, our method and apparatus allow indirect observation. The shape of
the sensitivity curve will quantify the effects of reducing overhead in a real system, limited by Am-
dahl’s Law of course. A steep slowdown curve would show that overhead reduction would have an
immediate, positive impact.
A new use of our apparatus in this chapter was the scaling of latency into the WAN range.
While performing adequately in this context, it was clear from the results that neither NFS nor the
SPECsfs benchmark are suited to run over this class of networks. While not entirely surprising, our
methodology showed it can quantify some of the strange effects that happen at these long latencies.
5.6.2
NFS Behavior
On the behavior side, one primary result is that in typical SAN and switched LAN envi-
ronments, the latency is quite satisfactory for NFS. Latencies under 150
ç
s are easily obtainable in
these environments, even when cascading switches. Further reductions will have little benefit.
In the WAN range, we have seen that the changes to NFS version 3 indeed improve perfor-
mance. However, such latencies are still a significant performance drag, as was also found in [21].
Qualitatively, the changes in Version 3 have raised the level of NFS performance over WANs from
“unusable” to merely “slow”. Even with these enhancements however, it may not be economically
viable to use NFS over WAN ranges. Given the low cost of disk storage compared with WAN links,
it may make more sense to replicate the entire data-set. Even for large amounts of data, the storage
requirements are cheap compared with the recurring costs of WAN links.
The SPECsfs workload has minimal bandwidth needs and is quite regular; generating traf-
fic on the order of single MB/s. However, real networks exhibit quite bursty behavior and thus band-
width requirements would be higher, but not into the gigabit range.

---

97
5.6.3
Architecture
In the architectural arena, overhead continues to be a performance limiter, much as it is for
the Split-C/AM programs, and this is where significant performance improvements could be made.
A similar conclusion as was found in [49] as well. The study examined three points in the network-
ing space (ATM, Autonet and FDDI), rather than systematically varying overhead. However, it is
encouraging that two different studies have come to the same conclusions by much different meth-
ods.
Although the networking overhead was only 20% of the entire service time, that does not
mean that attempts to reduce
è
will yield marginal results. Indeed, networking overhead is one of
the primary components of the service time. However, a number of subsystems must be improved
at once for significant progress to be made. For example, a combination of novel overhead reduc-
ing interfaces between major OS sub-systems, disks and network interfaces might yield significant
improvements.
Turning to latency, the architectural improvements in
é
from IP switches, which place
much of routing logic in silicon, will have a large impact on NFS. The order of magnitude drop in
é
from the millisecond to the 10-20
ê
s region [98, 99] will expand the range of NFS to a much wider
area. Recent switches also offer increased port densities, ranging to 100’s of ports at 100 Mb Ether-
net speeds. A network composed of these low-latency, high-density IP switches would expand the
range of NFS service to a whole campus, even multiple campuses, instead of it’s traditional domain,
a building. The implications of such an expansion are interesting; NFS service could reach a much
larger number of machines than previously possible.
For bandwidth, network technologies such as switched 100Mb Ethernet and 155 Mb ATM
provide plenty of bandwidth for NFS workloads. Given that most NFS packets are quite small, over-
head, rather than bandwidth or latency, will still be the dominant factor facing future network design-
ers.
5.6.4
Modeling
Simple queuing models are quite effective in analyzing the behavior of an NFS server. We
were able to model changes in response time, slope and saturation point for a variety of parameters,
although more investigation is needed to better describe the effect of latency on response time. We
empirically measured and validated the inputs to the model. However, one could obtain close to the
same inputs for a specific configuration by looking at the data published data on SPEC’s website [95].

---