WavebreakmediaMicro - Fotolia
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.
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:
- Ping measures round-trip times between your computer and an internet destination.
- Traceroute measures the response times of all the routers along the path between your computer and an internet destination.
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:
- For Windows: Ping /n 50 destination
- For Mac OS X and Linux: Ping -c 50 destination
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 -- 18.104.22.168 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:
- Start > Network > Network and Sharing Center > Manage Network Settings
- Right-click the Local Area Connection icon or appropriate wireless connection icon and select Properties.
On a Mac, go through the following:
- System Preferences > Network.
- Select your LAN or Wi-Fi connection, then Advanced > TCP/IP.
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:
- 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 [22.214.171.124]
- 7 ms 7 ms 8 ms ge9-0.dcr2.dc-fremont-ca.us.xo.net [126.96.36.199]
- 7 ms 7 ms 7 ms ge2-0.dcr1.dc-fremont-ca.us.xo.net [188.8.131.52]
- 10 ms 7 ms 8 ms p5-1-0-2.rar2.sanjose-ca.us.xo.net [184.108.40.206]
- 10 ms 9 ms 11 ms p1-0.ir1.paloalto-ca.us.xo.net [220.127.116.11]
- 9 ms 10 ms 15 ms 18.104.22.168.ptr.us.xo.net [22.214.171.124]
- 9 ms 10 ms 10 ms svl-core-03.inet.qwest.net [126.96.36.199]
- 29 ms 28 ms 29 ms stl-core-02.inet.qwest.net [188.8.131.52]
- 30 ms 29 ms 29 ms sea-edge-03.inet.qwest.net [184.108.40.206]
- * * * Request timed out.
- * * * Request timed out.
- 28 ms 28 ms 29 ms sam.abcnews.go.com [220.127.116.11]
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.
Learn what causes packet loss across the WAN
Tactics for diagnosing packet loss
Is packet loss the cause of poor WAN performance?
Dig Deeper on Mobile and wireless network technology
Related Q&A from John Burke
Organizations might sometimes consider cloud computing and cloud networking as interchangeable due to their similarities. But the two strategies have... Continue Reading
Organizations may want to consider the effect SD-WAN and edge computing could have when combined. Make sure to consider all options before choosing a... Continue Reading
A half-duplex transmission could be considered a one-way street between sender and receiver. Full-duplex, on the other hand, enables two-way traffic ... Continue Reading