Networking.com

How to perform packet loss tests and how they work

By John Burke

In this Q&A, our expert explains how to conduct a packet loss test using ping and traceroute when audio and video are not performing well over your broadband connection.

Problems with real-time media across the internet are often the result of packet loss, rather than connection speed, per se.

What is packet loss? Why is it bad?

It is quite literal: A packet sent was lost before it reached its intended destination.

Sometimes, a router, switch, firewall or other system in the internet has more traffic coming at it than it can handle. One standard way to deal with such congestion is to drop packets -- just throw them away -- to focus capacity on the rest of the traffic. Intentionally dropped packets are the No. 1 source of packet loss in the internet. Other causes include equipment failure, equipment degradation and transmission errors due to interference, especially with wireless connections.

Some protocols, like TCP/IP, retransmit dropped packets. TCP underlies things like web browsing and email. The resulting small hiccups in performance are not visible to end users for many applications. Other protocols, like User Datagram Protocol (UDP), do not retransmit packets. Lost packets are lost. UDP underlies most streaming media, and missed packets are visible or audible as video or audio glitches.

Where are packets being lost?

Packet loss can occur anywhere along the path between your computer and the destination with which you are trying to communicate. A packet loss test can help determine where along the path the problem is and whether it is persistent or transient.

Network engineers often have specialized network analysis tools. Everyone else can use two standard system utilities -- ping and traceroute -- to conduct packet loss tests and find where packets are going astray:

How to use ping as a packet loss test

Ping works by sending special packets to the destination given and then watching to see if the node at the far end responds correctly. The best way to measure packet loss using ping is to send a large number of pings to the destination and look for failed responses. For instance, if you ping something 50 times and get only 49 responses, you can estimate packet loss at roughly 2% at the moment. Anything over 5% is of concern.

To do this on a Windows computer or a Mac, use the ping command at a system command prompt:

The /n or -c tell ping to send a set number of pings, and 50 is the number to send.

The destination can be an IP address or a domain-name-system name -- 206.19.49.153 or searchnetworking.com, for example.

You will see a record of each packet sent and whether a response has been sent back. At the end of the test, you will get a summary of the results of your packet loss test.

Very high average round-trip times -- greater than 100 milliseconds -- are termed high packet latency, which can also cause performance problems and slow network downloads. Variation in latency, known as jitter, is especially bad for real-time applications; it's worse for performance than consistently high latencies.

One way to try to eliminate certain parts of the network that may cause 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 router. 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.

How to find the IP address of your default gateway

You can find the IP address of your default gateway in Windows through the following:

On a Mac, go through the following:

How to use traceroute to find network problems

Route traces can be run using the traceroute command at a command prompt in Windows (tracert destination) or Mac OS X (traceroute destination).

Traceroute is not a direct packet loss test; it will show you the response time for packets sent to each router on the path from you to the destination. It can, therefore, show you where there are slow-responding or nonresponding routers along the path, which usually indicates congestion and probable high packet loss in those places.

This is example output:

  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 response times greater than 100 milliseconds -- one-tenth of a second -- expect application performance to degrade. Big variations in response time to a given router in the path indicates jitter and will also cause problems.

In the above example, you can see that data traverses lots of different networks -- Concentric, XO, Qwest, ABC. On repetitions, you might see different lists of nodes, as the internet is dynamic and routes can shift in response to factors such as changes in demand and router performance problems. The upside is traffic usually gets through. A downside is troubleshooting a problem with slow response times is out of the hands of individual users.

How to know if you have packet loss

The best place to start with a packet loss test is to make sure there is not packet loss between you and your service provider, followed by traceroutes to look for loss, latency and jitter along the rest of the path.

If the problem is on the first hop, your provider may be able to help resolve them. They may be able to help when the problem is on some other network, as well: If one of the intermediate hops is consistently a problem, your provider may be able to either change how traffic is routed to avoid that intermediary or raise a trouble ticket with that node's provider.

25 Oct 2018

All Rights Reserved, Copyright 2000 - 2024, TechTarget | Read our Privacy Statement