Q

How to test for packet loss on a broadband connection

In this Q&A, our expert explains how to measure your broadband connection for packet loss by using ping and trace route.

In this Q&A, our expert explains how to measure your broadband connection for packet loss by using ping and trace route.

How do I conduct a packet loss test? When I do a speed test, it is way down from what it used to be, and I haven't changed any hardware or added any new applications.

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 for a packet loss test

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 packet loss 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.

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:

  1. 5 ms 2 ms 3 ms malibu.domain.com [10.10.0.1]
  2. 10 ms 6 ms 7 ms 10.60.0.6
  3. 9 ms 7 ms 7 ms 10.20.0.1
  4. 6 ms 7 ms 7 ms x130.cd9e68.sj.concentric.net [205.158.104.130]
  5. 7 ms 7 ms 8 ms ge9-0.dcr2.dc-fremont-ca.us.xo.net [205.158.60.169]
  6. 7 ms 7 ms 7 ms ge2-0.dcr1.dc-fremont-ca.us.xo.net [65.106.2.205]
  7. 10 ms 7 ms 8 ms p5-1-0-2.rar2.sanjose-ca.us.xo.net [65.106.2.153]
  8. 10 ms 9 ms 11 ms p1-0.ir1.paloalto-ca.us.xo.net [65.106.5.178]
  9. 9 ms 10 ms 15 ms 206.111.12.114.ptr.us.xo.net [206.111.12.114]
  10. 9 ms 10 ms 10 ms svl-core-03.inet.qwest.net [205.171.205.29]
  11. 29 ms 28 ms 29 ms stl-core-02.inet.qwest.net [205.171.5.85]
  12. 30 ms 29 ms 29 ms sea-edge-03.inet.qwest.net [205.171.26.42]
  13. * * * Request timed out.
  14. * * * Request timed out.
  15. 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 with a packet loss test is to make sure that there is not packet loss between yourself and your service provider.

Next Steps

Learn what causes packet loss across the WAN

Tactics for diagnosing packet loss

Is packet loss the cause of poor WAN performance?

This was first published in June 2008

Dig deeper on IP Networking

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close