data link Story: Step 1: Use ping to test network connectivity

Top | Step 1 | Step 2 | Step 3

Step 1: Use ping to test network connectivity

The first step is to find out whether your workstation can reach a remote machine and to see how much time a packet takes to make a round trip.

This example runs the ping utility from modi4.ncsa.uiuc.edu at NCSA to golden.sdsc.edu at SDSC. NCSA and SDSC are connected to the vBNS.

modi4 53% /usr/etc/ping golden.sdsc.edu
PING golden.sdsc.edu (132.249.40.55): 56 data bytes
64 bytes from 132.249.40.55: icmp_seq=0 ttl=249 time=59.526 ms
64 bytes from 132.249.40.55: icmp_seq=1 ttl=249 time=60.185 ms
64 bytes from 132.249.40.55: icmp_seq=2 ttl=249 time=61.619 ms
64 bytes from 132.249.40.55: icmp_seq=3 ttl=249 time=61.528 ms
64 bytes from 132.249.40.55: icmp_seq=4 ttl=249 time=62.803 ms
64 bytes from 132.249.40.55: icmp_seq=5 ttl=249 time=63.774 ms
64 bytes from 132.249.40.55: icmp_seq=6 ttl=249 time=62.404 ms
64 bytes from 132.249.40.55: icmp_seq=7 ttl=249 time=60.208 ms
----golden.sdsc.edu PING Statistics----
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max = 59.526/61.506/63.774 ms

The result shows the RTT (round trip times) for each of the packets and the average RTT (61.5 milliseconds). Note this number because you can use this timing to calculate an optimal "TCP window size" later.

The ping utility works by sending echo-request packets to the remote machine and waiting for the echo-reply packets. Different versions of ping are available depending on the operating system of the machine where you issue the command. Some versions return "host is alive" by default. Check the man page of ping on your machine to verify the command-line arguments. Useful command-line arguments include the number of packets (-c # option) and the packet size (-s # option) that, if unspecified, usually defaults to 64 bytes.

A reasonable diagnostic strategy consists of sending a fair number of packets, say 100, with a larger packet size such as 1000 bytes or the packet size your application will be using (ping -c 100 -s 1000 golden.sdsc.edu ). Usually 1-3% packet loss is not a problem, but each percentage point of packet loss causes an exponentially growing loss of application performance over that connection. If you notice over 10% loss, it may indicate an overloaded router on the path or another serious problem. These problems are often transient, but if they persist contact your local network operations staff or NLANR engineering support if the problem appears to be in the wide-area network (WAN).

If the remote host is unreachable, try to ping another machine within your domain. This may help to isolate the network connectivity problem. If it turns out to be a WAN problem, you can get help from NLANR engineering support by emailing ncne@ncne.nlanr.net or by calling tollfree 1-800-962-NCNE. Check out the engineering support web page at ncne.nlanr.net for more advanced network diagnostic tools.