DOC《英文翻译：本文出自《Computer Network》第四版 Andrew ...》

英文翻译:本文出自《Computer Network》第四版 Andrew S.

Tanenbaum 著Network Performance Measurement When a network performs poorly, its users often complain to the folks running it, demanding improvements. To improve the performance, the operators must first determine exactly what is going on. To find out what is really happening, the operators must make measurements. In this section we will look at network performance measurements. The discussion below is based on the work of Mogul (1993). The basic loop used to improve network performance contains the following steps: Measure the relevant network parameters and performance. Try to understand what is going on. Change one parameter. These steps are repeated until the performance is good enough or it is clear that the last drop of improvement has been squeezed out. Measurements can be made in many ways and at many locations (both physically and in the protocol stack). The most basic kind of measurement is to start a timer when beginning some activity and see how long that activity takes. For example, knowing how long it takes for a TPDU to be acknowledged is a key measurement. Other measurements are made with counters that record how often some event has happened (e.g., number of lost TPDUS). Finally, one is often interested in knowing the amount of something, such as the number of bytes processed in a certain time interval. Measuring network performance and parameters has many potential pitfalls. Below we list a few of them. Any systematic attempt to measure network performance should be careful to avoid these. Make Sure That the Sample Size Is Large Enough Do not measure the time to send one TPDU, but repeat the measurement, say, one million times and take the average. Having a large sample will reduce the uncertainty in the measured mean and standard deviation. This uncertainty can be computed using standard statistical formulas. Make Sure That the Samples Are Representative Ideally, the whole sequence of one million measurements should be repeated at different times of the day and the week to see the effect of different system loads on the measured quantity. Measurements of congestion, for example, are of little use if they are made at a moment when there is no congestion. Sometimes the results may be counterintuitive at first, such as heavy congestion at 10, 11, 1, and

2 o'

clock, but no congestion at noon (when all the users are away at lunch). Be Careful When Using a Coarse-Grained Clock Computer clocks work by incrementing some counter at regular intervals. For example, a millisecond timer adds

1 to a counter every

1 msec. Using such a timer to measure an event that takes less than

1 msec is possible, but requires some care. (Some computers have more accurate clocks, of course.) To measure the time to send a TPDU, for example, the system clock (say, in milliseconds) should be read out when the transport layer code is entered and again when it is exited. If the true TPDU send time is

300 ?sec, the difference between the two readings will be either

0 or 1, both wrong. However, if the measurement is repeated one million times and the total of all measurements added up and divided by one million, the mean time will be accurate to better than

1 ?sec. Be Sure That Nothing Unexpected Is Going On during Your Tests Making measurements on a university system the day some major lab project has to be turned in may give different results than if made the next day. Likewise, if some researcher has decided to run a video conference over your network during your tests, you may get a biased result. It is best to run tests on an idle system and create the entire workload yourself. Even this approach has pitfalls though. While you might think nobody will be using the network at