Wednesday, March 14, 2012

How to test for packet loss on a broadband connection

SkyHi @ Wednesday, March 14, 2012
Measuring packet loss from home over a broadband connection can be a difficult task. Packet loss can occur anywhere along the path between your computer and the destination you are trying to reach over the Internet. Packet loss is typically a result of one or more of the following: network congestion, overworked routers and switches, slow roundtrip times, or possibly a result of traffic prioritization schemes used by service providers or the company hosting the site you are trying to access.

Without actively measuring the TCP flows of actual retransmissions (these products are usually too expensive to use for a home broadband connection), it is hard to determine if there are real retransmissions occurring. The mechanisms you mentioned, ping and trace route, are the most readily available tools for at-home users for helping to determine where there is slowness on the Internet. Ping measures the roundtrip time between your computer and the IP address you are pinging. Trace route measures the response times of the routers along the path between your computer and the IP address you are trace routing.

Using Ping

The best way to measure packet loss using ping is to send a large number of pings to an IP address, and then look for failed responses to those pings. For instance, if you ping something 50 times in a rapid fashion, you can measure the number of failed responses and use this as an estimate of "packet loss." Anything over five percent is probably something to be concerned about.

On a Windows machine, this can be accomplished by using the following command at the command prompt:

Ping -n 50 (IP Address or domain name [www.website.com])>
The "–n" tells ping to send a set number of pings, and "50" is the number to send.

Afterwards, you will get a summary of the test that includes the number lost and a percentage:

Ping statistics for 199.181.132.250:
Packets: Sent = 6, Received = 6, Lost = 0 (0%)
Approximate round trip times in milliseconds:
Minimum = 26ms, Maximum = 29ms, Average = 27ms
If you see a very high average roundtrip time (greater then 100ms), this will also cause you to experience slow network downloads.

One way to try to eliminate certain parts of the network that may be the cause of packet loss is to do the ping test along various segments along the path. The first place I normally start testing is the local "default gateway." This is the first router that all your data is transmitted to on the network. If there is high packet loss on this segment, then the problem is localized to your service provider's network.

You can find the IP address of your default router by typing in the "ipconfig" command at your Windows command prompt. This will display the following:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix_: domainname.com
IP Address. . . . . . . . . . . . : 192.168.2.189
Subnet Mask . . . . . . . . . . . : 255.255.252.0
Default Gateway . . . . . . . . . : 10.10.0.1
What you are looking for is the default gateway IP address. In the example above, it is 10.10.0.1.

Using Trace route

Trace routes can be run by using the trace route command at the Windows command prompt. On Windows XP this is:

tracert (IP Address or Hostname)
While the output doesn't show you packet loss, it will show you if there are slow-responding routers along the path.

The output will show you the response time of all the routers. The following is an example:

5 ms 2 ms 3 ms malibu.domain.com [10.10.0.1]
10 ms 6 ms 7 ms 10.60.0.6
9 ms 7 ms 7 ms 10.20.0.1
6 ms 7 ms 7 ms x130.cd9e68.sj.concentric.net [205.158.104.130]
7 ms 7 ms 8 ms ge9-0.dcr2.dc-fremont-ca.us.xo.net [205.158.60.169]
7 ms 7 ms 7 ms ge2-0.dcr1.dc-fremont-ca.us.xo.net [65.106.2.205]
10 ms 7 ms 8 ms p5-1-0-2.rar2.sanjose-ca.us.xo.net [65.106.2.153]
10 ms 9 ms 11 ms p1-0.ir1.paloalto-ca.us.xo.net [65.106.5.178]
9 ms 10 ms 15 ms 206.111.12.114.ptr.us.xo.net [206.111.12.114]
9 ms 10 ms 10 ms svl-core-03.inet.qwest.net [205.171.205.29]
29 ms 28 ms 29 ms stl-core-02.inet.qwest.net [205.171.5.85]
30 ms 29 ms 29 ms sea-edge-03.inet.qwest.net [205.171.26.42]
* * * Request timed out.
* * * Request timed out.
28 ms 28 ms 29 ms sam.abcnews.go.com [199.181.132.250]
If you see trace route roundtrip times along the path greater than 100ms (1/10th of a second), this can cause slow transfer times over the network.

From the above, you can see that data travels along lots of different networks (XO, Qwest, ABC). This is part of the beauty of the Internet. The downside is that it places the ability to resolve slow response times out of the hands of individual users. The best place to start is to make sure that there is not packet loss between yourself and your service provider.



Measuring packet loss

n continuing on with my commitment to describe my favorite network utilities, I bring to you mtr:
$ mtr -r -c 10 mail.prefetch.net
HOST: me                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 10.238.4.1                    0.0%    10    9.2   8.2   5.4  12.6   2.1
  2. 68.86.108.13                  0.0%    10    9.2   9.4   6.3  14.9   2.8
  3. 68.86.106.45                  0.0%    10   15.1  10.1   6.9  17.5   3.5
  4. 68.86.106.13                  0.0%    10   14.0  11.0   5.7  22.1   4.8
  5. 68.86.106.9                   0.0%    10   14.6  11.4   7.2  18.5   3.6
  6. 12.118.120.89                 0.0%    10   10.2  10.3   8.2  14.6   2.2
  7. tbr1-p012201.attga.ip.att.ne  0.0%    10   23.8  25.8  21.8  33.9   3.6
  8. tbr2-cl1.wswdc.ip.att.net     0.0%    10   27.3  26.9  23.7  33.4   3.0
  9. ggr2-p390.wswdc.ip.att.net    0.0%    10   23.0  27.6  22.6  41.0   5.6
 10. so6-3-0-2488M.ar1.DCA3.gblx.  0.0%    10   26.0  30.4  23.9  43.3   6.3
 11. so0-0-0-622M.ar2.CLE1.gblx.n  0.0%    10  130.3  49.8  37.7 130.3  28.4
 12. Enet-Inc-Internet.so-0-3-3.a  0.0%    10   51.2  45.9  42.5  54.9   4.0
 13. extreme.xlhost.com            0.0%    10   44.2  67.1  41.4 261.4  68.3
 14. mail.prefetch.net            0.0%    10   48.3  56.6  41.5 172.9  40.9
mtr allows you to view hop-by-hop latency metrics, and is invaluable for finding busy devices between two endpoints. Some routers will place low QOS priorities on ICMP traffic, so it is important to capture traffic at various intervals to see if a device is truly overloaded.


REFERENCES
http://searchnetworking.techtarget.com/answer/How-to-test-for-packet-loss-on-a-broadband-connection
http://nixcraft.com/centos-rhel-fedora/15483-showing-packet-loss-interface.html
http://prefetch.net/blog/index.php/2005/08/29/measuring-packet-loss/