• Choose a category
• All
• Classic-Fiction

% ping -s mahimahi

PING mahimahi: 56 data bytes

64 bytes from mahimahi (131.40.52.28): icmp_seq=0. time=3. ms

64 bytes from mahimahi (131.40.52.28): icmp_seq=1. time=2. ms

64 bytes from mahimahi (131.40.52.28): icmp_seq=16. time=1295. ms

64 bytes from mahimahi (131.40.52.28): icmp_seq=17. time=3. ms

64 bytes from mahimahi (131.40.52.28): icmp_seq=18. time=2. ms

The gap between packets 1 and 16, along with the exceptionally long packet delay, indicates that a low-level network problem is consuming packets.

Gauging Ethernet interface capacity

Even with a well-conditioned network and proper host configuration information, a server may have trouble communicating with its clients because its network interface is overloaded. If an NFS server is hit with more packets than it can receive through its network interface, some client requests will be lost and eventually retransmitted. To the NFS clients, the server appears painfully slow, when it's really the server's network interface that is the problem.

The spray utility provides a very coarse estimate of network interface capacity, both on individual hosts and through network hardware between hosts. spray showers a target host with consecutive packets of a fixed length by making remote procedure calls to the rpc.sprayd daemon on the remote host. After the last packet is sent, the rpc.sprayd daemon is queried for a count of the packets received; this value is compared to the number of packets sent to determine the percentage dropped between client and server.

On its own, spray is of limited usefulness as a measure of the packet handling capability of a machine. The packet containing the RPC call may be lost by the client, due to other activity on its network interface; it may be consumed by a collision on the network; or it may be incident to the server but not copied from the network by the server's network interface due to a lack of buffer space or excessive server CPU loading. Many packets are lost on the sending host, and spray has no knowledge of where the packets vanish once they get pass the application layer. Due to these factors, spray is best used to gauge the relative packet-handling speeds of two or more machines.

Here are some examples of using spray to test various network constraints. spray requires a hostname and takes a packet count, delay value, and packet length as optional arguments:

spray [-c count] [-d delay] [-l length] host

For example:

% spray wahoo

sending 1162 packets of length 86 to wahoo ...

675 packets (58.090%) dropped by wahoo

1197 packets/sec, 103007 bytes/sec

spray reports the number of packets received, as well as the transfer rate. The packet drop rates are only meaningful when used to compare the relative network input and output rates of the two machines under test.

It's important to note that network interface speed depends upon much more than CPU speed. A faster CPU helps a host process network protocols faster, but the network interface and bus hardware usually determine how quickly the host can pull packets from the network. A fast network interface may be separated from the CPU by a bus that has a high latency. Even a high-throughput I/O system may exhibit poor network performance if there is a large time overhead required to set up each packet transfer from the network interface to the CPU. Similar hosts stress each other fairly, since their network interfaces have the same input capacity.

Even on a well-conditioned, little-used network, a client machine that has a significantly faster CPU than its server may perform worse under the stress of spray than the same two machines with the client and server roles reversed. With increased CPU speed comes increased packet handling speed, so a faster machine can transmit packets quickly enough to outpace a slower server. If the disparity between client and server is great, then the client is forced to retransmit requests and the server is additionally burdened with the duplicate requests. Use spray to exercise combinations