外文翻译--网络性能的测量

《外文翻译--网络性能的测量》由会员分享，可在线阅读，更多相关《外文翻译--网络性能的测量（6页珍藏版）》请在毕设资料网上搜索。

1、中文 2100 字 英文翻译：出自 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 wh

2、at 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: 1. Measure the relevant network

3、parameters and performance. 2. Try to understand what is going on. 3. 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 physical

4、ly 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 ho

5、w 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.

6、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

7、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

8、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 oclock, but no congestion at noon

9、 (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 possi

10、ble, 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,

11、 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 O

12、n 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.

13、 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 3 A.M., that might be precisely when the automatic backup program begins copying all the disks to tape. Furthermore, t

14、here might be heavy traffic for your wonderful World Wide Web pages from distant time zones. Caching Can Wreak Havoc with Measurements The obvious way to measure file transfer times is to open a large file, read the whole thing, close it, and see how long it takes. Then repeat the measurement many m

15、ore times to get a good average. The trouble is, the system may cache the file, so only the first measurement actually involves network traffic. The rest are just reads from the local cache. The results from such a measurement are essentially worthless (unless you want to measure cache performance).

16、 Often you can get around caching by simply overflowing the cache. For example, if the cache is 10 MB, the test loop could open, read, and close two 10-MB files on each pass, in an attempt to force the cache hit rate to 0. Still, caution is advised unless you are absolutely sure you understand the c

17、aching algorithm. Buffering can have a similar effect. One popular TCP/IP performance utility program has been known to report that UDP can achieve a performance substantially higher than the physical line allows. How does this occur? A call to UDP normally returns control as soon as the message has

18、 been accepted by the kernel and added to the transmission queue. If there is sufficient buffer space, timing 1000 UDP calls does not mean that all the data have been sent. Most of them may still be in the kernel, but the performance utility thinks they have all been transmitted. Understand What You

19、 Are Measuring When you measure the time to read a remote file, your measurements depend on the network, the operating systems on both the client and server, the particular hardware interface boards used, their drivers, and other factors. If the measurements are done carefully, you will ultimately d

20、iscover the file transfer time for the configuration you are using. If your goal is to tune this particular configuration, these measurements are fine. However, if you are making similar measurements on three different systems in order to choose which network interface board to buy, your results could be thrown off completely by the fact that one of the network drivers is truly awful and is only getting 10 percent of the performance of the board.