Packet pair software Bandwidth Measurements

68 --- 205.153.60.2 statistics --- bytes out in dup loss rtt ms: min avg max 44 10 10 0 3.385 3.421 3.551 108 10 10 0 3.638 3.684 3.762 --- 165.166.36.17 statistics --- bytes out in dup loss rtt ms: min avg max 44 10 10 0 3.926 3.986 4.050 108 10 10 0 4.797 4.918 4.986 --- estimated link characteristics --- estimated throughput 1656958bps minimum delay per packet 0.116ms 192 bits average statistics experimental : packet loss: small 0, big 0, total 0 average throughput 1528358bps average delay per packet 0.140ms 232 bits weighted average throughput 1528358bps resetting after 10 samples. The output begins with the addresses and packet sizes followed by lines for each pair of probes. Next, bing returns round-trip times and packet loss data. Finally, it returns several estimates of throughput. [4] [4] The observant reader will notice that bing reported throughput, not bandwidth. Unfortunately, there is a lot of ambiguity and inconsistency surrounding these terms. In this particular example, we have specified the options -e10 and -c1, which limit the probe to one cycle using 10 pairs of packets. Alternatively, you can omit these options and watch the output. When the process seems to have stabilized, enter a Ctrl-C to terminate the program. The summary results will then be printed. Interpretation of these results should be self-explanatory. bing allows for a number of fairly standard options. These options allow controlling the number of packet sizes, suppressing name resolution, controlling routing, and obtaining verbose output. See the manpage if you have need of these options. Because bing uses the same mechanism as pathchar, it will suffer the same problems with hidden transmission points. Thus, you should be circumspect when using it if you dont fully understand the topology of the network. While bing does not generate nearly as much traffic as pathchar, it can still place strains on a network.

4.2.2.4 Packet pair software

One alternative approach that is useful for measuring bottleneck bandwidth is the packet pair or packet stretch approach. With this approach, two packets that are the same size are transmitted back- to-back. As they cross the network, whenever they come to a slower link, the second packet will have to wait while the first is being transmitted. This increases the time between the transmission of the packets at this point on the network. If the packets go onto another faster link, the separation is preserved. If the packets subsequently go onto a slower link, then the separation will increase. When the packets arrive at their destination, the bandwidth of the slowest link can be calculated from the amount of separation and the size of the packets. It would appear that getting this method to work requires software at both ends of the link. In fact, some implementations of packet pair software work this way. However, using software at both ends is 69 not absolutely necessary since the acknowledgment packets provided with some protocols should preserve the separation. One assumption of this algorithm is that packets will stay together as they move through the network. If other packets are queued between the two packets, the separation will increase. To avoid this problem, a number of packet pairs are sent through the network with the assumption that at least one pair will stay together. This will be the pair with the minimum separation. Several implementations of this algorithm exist. bprobe and cprobe are two examples. At the time this was written, these were available only for the IRIX operating system on SGI computers. Since the source code is available, this may have changed by the time you read this. Compared to the pathchar approach, the packet pair approach will find only the bottleneck bandwidth rather than the bandwidth of an arbitrary link. However, it does not suffer from the hidden hop problem. Nor does it create the levels of traffic characteristic of pathchar. This is a technology to watch.

4.2.3 Throughput Measurements