You are on an important video-conference, and the quality of video keeps degrading, making it impossible for you to pay attention and even see people’s faces. Or maybe you are talking over a VoIP call, and the voice sounds much like a robot, which is impossible for keeping a normal conversation.
These are a few symptoms of Packet Loss.
A 5% packet loss and few microseconds of delay can make all the difference between winning and losing in online video-gaming. It can also degrade the multimedia streaming quality and VoIP communication.
Although some applications have their way of dealing with it, such as turning your voice quality down to the point where you sound like a robot or lowering video quality, packet loss is still the real pain that kills high-quality communication. But what is packet loss?
In simple words, Packet Loss (read the full definition here) is when pieces of data traveling from source to destination go off track, never to be found again.
There are many reasons why some packets are lost, for example, the networking hardware is faulty, a cable is damaged, the link is congested, a source/destination device is over-utilized, wireless interference, weak Wifi signal, or bugs and viruses in the system.
But hey, don't worry. Fortunately, you can find the possible sources of data loss by running the following simple tests.
What Results are We Looking For?
We are looking for a difference (in %) between the number of packets sent and the number of packets received.
But before doing the Packet Loss Test, let’s dig into some theory.
Although we can generally perceive data packet loss in communication thanks to its symptoms, there is an essential player behind the curtains. The TCP/IP communication model is the one that detects it on a packet level and allows us to create statistics.
How does TCP/IP Detect Packet Loss?
When transferring data, the TCP/IP of the sender (or Client) keeps track of a sequence (seq) number of packets.
The receiver (Server) sends back an acknowledge (ack) for each packet received.
With this information, the sender can reconstruct the entire sequence number from the received ACK packets and calculate a percentage of packet loss (among other metrics).
The TCP/IP model is the key to computer communications because it makes sure that all data packets are delivered successfully. When TCP/IP detects packet loss, the transmitter will resend packets of segments that have not been acknowledged by the receiver, or the receiver will ask for re-transmission.
How to Test Packet Loss on Windows?
You don’t need Hi-Tech software to find your packet loss.
Fortunately, Windows (and other OS) have native tools that can show you a percentage. You will be using commands such as “ipconfig” to gather information on your network adapter, and “ping” to analyze replies on specific targets and gather packet loss results – You can see a full list of Network Troubleshooting tools here.
We will perform two tests:
- One showing packet loss due to wireless signal coverage.
- The other, a communication without packet loss.
Our scenario is the standard wireless home network. We are using a Windows 10 machine connected to a WiFi home network. The Access Point “AP” acts as the router and the gateway to the Internet.
1. Opening The Necessary Tools
To run a Packet Loss test in Windows, you need to open the Command Line Interface “cmd” on Windows.
To do this, open the “Run” application, simply hold down the Windows key + R, then type “cmd”
You can also find the cmd, by typing “cmd” in the Windows Menu search bar.
Open the “Command Prompt” or cmd application in Windows.
2. Performing The Tests
Packet Loss Due to Wireless Coverage:
The first test will be done on the internal network with a “Ping” to the Wireless AP.
We are intentionally located far away from the AP and between concrete walls to prove the % packet loss due to wireless signal coverage.
First, we need to find the IPv4 address of our AP. The “ipconfig” command shows the IP configuration of your network adapter.
In our case, the Wireless LAN adapter Wi-Fi section at the bottom shows IPv4, IPv6, Subnet Mask, and Default Gateway (our Wireless AP).
Now, let’s ping the wireless AP (default gateway).
Run a “ping (Target IP) -n 25” as seen below (you'll need to replace the Target IP with your Default gateway IP as seen above).
The command will send 25 ICMP packets to the AP, will wait for their reply, calculate a % of packet loss, and an average RTT (Round Trip Time in ms).
As you can see from the screenshot above, our communication is pretty bad.
From 25 packets sent, 17 were received, and eight were lost, that is 32% of Packet Loss. Even the average RTT (308ms) on average proves that this specific wireless communication is in bad shape.
Packet Loss Due to Network Congestion:
In this test, we are going to be moving next to the Wireless AP and will send a ping test to the outside network. Wireless packet loss shouldn’t be a great deal in this test.
Now, we are going to test the Internet connection against “possible” network congestion, specifically to google.com. Usually, Google servers are highly reliable and stable, so there shouldn’t be a problem regarding the destination. But there are still many hops from here towards the Google servers. The target is in a geographically distant place, so each packet has to travel through many different devices.
Fortunately, there was no network congestion from source (our IP, 192.168.0.104) to the destination (google’s public IP, 22.214.171.124). In the same case, wireless communication didn’t affect packet loss. Of the 25 packets that were sent, all of them were received (0 lost.) That is 0% of packet loss.
3. Analyzing The Results
We obtained a 32% packet loss in the first test and 0% packet loss in the second test.
The results prove that wireless networks are highly vulnerable to factors that hurt packets traveling through the air such as RF interference, signal coverage, or weak signals.
Our second packet loss test was aimed at measuring the Internet network congestion. Rather than connecting directly to the router, we put the computer next to the Wireless AP. Although wireless can still impact packet loss here, it tends to be less probable.
All the ping (ICMP packets) sent to google.com traveled through many hops, and all came back to the source. There was no packet loss here.
|Destination||Internal/External||No. of Packets||Sent||Received||Lost||Packet Loss %|
The bottom line…
If you are experiencing packet loss, but don’t know the source, try running these tests at different times of the day, in different places, and with various devices.
The results of these tests will help you determine the possible causes of packet loss.
- If you move your laptop and experience different % of packet loss, then it might be a wireless or cabling issue (if you connect to another Ethernet port).
- If you experience different packet loss at various times during the day, then there is a chance that you have network congestion.
- If you experience different packet loss with multiple devices, then it might be an issue of updates, media (bad wires or wireless), or even damaged hardware.
- If your results show packets lost when sent, then it might be a problem with your network adapter.
Automated network performance monitoring
The professional solution to spotting packet loss is to automate detection with a monitoring tool. There are many available and they range in price. However, there are some very good, expensive network monitoring tools that you can get for free. Paessler PRTG is an example. With such a tool you can get simultaneous traces for a variety of conditions on all traffic. For example, if you need to watch packet loss to ensure a clean service for VoIP or video streaming, you really should be looking at jitter as well. PRTG has the QoS sensor, which takes care of both.
If you are still experiencing lousy quality streaming media, online video game lags, or the robotic-like sound in VoIP calls, then you might be suffering from packet loss. If you want to improve your communication, you must aim at 0 percent of packet loss.
Getting a faster Internet connection or a more powerful computer will not fix a packet loss problem. To deal with it and find the real source, you have to test many times and go deeper into the results.
For our case, we’ll try to keep our devices updated (Computer and Wireless AP), and we’ll stay within wireless coverage. Whatever happens, after the Gateway is the ISP’s or the destination responsibility.
If we ever experience the same kind of packet loss, we can conclude that it is because of our wireless.
Fortunately, you don’t need to buy expensive troubleshooting software, as this is 100% free, like many other troubleshooting tools and software we've reviewed. Running the simple tests on Windows shown above will give you an idea of the possible causes of your packet loss
How to Test Packet Loss on Windows FAQs
Why is packet loss a problem?
Packet loss can cause a variety of issues, such as decreased network performance, delays in data transmission, and increased error rates. This can lead to poor quality of service for applications and users, and can even cause the complete loss of connections.
How do I interpret the results of a packet loss test?
The results of a packet loss test will typically be reported as a percentage of lost packets. A low percentage of lost packets (e.g., less than 1%) is generally considered acceptable, while higher percentages can indicate a problem. It's important to note that packet loss can vary over time, so it is important to test multiple times or over a longer period of time to get a more accurate picture of the network performance.
What can cause packet loss?
Packet loss can be caused by a variety of factors, including:
- Network congestion: When too much data is trying to travel through the network at the same time, packets can get dropped.
- Faulty hardware: Packet loss can be caused by malfunctioning network devices such as routers, switches, and cables.
- Distance and signal quality: Packet loss can be caused by poor signal quality and the distance that packets have to travel.
- Overloaded servers: If a server is overwhelmed and can't handle the traffic it's receiving, packets may be dropped.