To test for packet loss, you must first have a way of measuring packets at both ends of your connection. You can figure out one end by issuing ping requests from the other – make sure you know the source’s IP address (for example, the source could be the DNS server you are using).
How do you test packet loss?
An easy way on how to test packet loss is to visit devicetests.com’s packet loss test, where you can choose specific presets according to your needs in testing.
A ping utility can be considered a “lightweight” packet; it’s not carrying much information (it’s not like opening an HTML file on your browser, which requires more than just one packet) – however, it is still useful for testing purposes.
Just make sure that any additional packets are required to go out within some short time frame after sending the original request. If you wait too long to send additional packets, there might not be enough time to reach their destination and return before your first ping times out!
Make sure your requests are spaced apart by at least 1ms so that they don’t clog up each other preventing the outgoing packets from being sent as quickly as possible.
Monitoring Packets
You can monitor your packets using an SNMP tool such as MRTG as well – this is useful for those who have a router that supports SNMP monitoring at the WAN interface. If you have a Netgear or Linksys router, there are instructions on how to do this online already!
Type of Traffic
The next step is to figure out what kind of traffic will be tested. Generally, it’s best to vary your tests by using different sized packets (small, medium, and large) along with several types of TCP/IP traffic (plaintext, HTTPS connection, etc.)
Alternatively, you could attempt to use ICMP echo requests which are supposed to be processed very quickly; however, their performance will depend on the protocol stack of the destination.
Kill All Unnecessary Applications
After choosing your test traffic, configure your source machine to stop unnecessary applications (particularly any ssh or FTP servers) before sending packets. Ideally, you should only be running one application on the source machine – this allows it to focus on sending packets making measurements more accurate.
Also, make sure that all firewalls are disabled (especially any built-in Windows firewall) in addition to anti-virus scanning software; whenever possible, disable UAC too!
If you’re using an operating system with a different firewall, don’t forget it can still affect packet loss, especially when trying to test UDP protocols! Keep in mind that each packet will require at least one header, usually around 40 bytes for TCP packets. However, you can save some bytes by using smaller UDP packets of around 40-60 bytes each.
Capture and Collect Data
Now that everything is ready to go, start capturing data on your monitoring interface. You may want to increase the capture buffer size if it’s too small for testing purposes (most cards will need at least 64KB of memory to stream 300 Mbps continuously); however, keep in mind that setting this value too high may affect performance which defeats the purpose of trying to measure packet loss!
Make sure not to change any other settings so as not to skew the results – also, make sure you run with no headroom so that no packets are dropped due to overflowing buffers!
Once you’ve collected all the data try sorting it by time or packet count; in general, the most packets lost in a period will be highlighted in red. If you see any sudden spikes, then this is where you should look next.
If your problem still isn’t solved, try running a continuous ping from the source machine to a known good address such as 8.8.8.8 every few minutes. This ensures that there will always be an echo packet sent back, which helps eliminate network congestion during testing, especially if you’re trying to test TCP connections!
However, keep in mind that sending packets all the time can impact your bandwidth but only very slightly since each ping packet is around 40 bytes for IPv4 and 60 bytes for IPv6.
While measuring packet loss, another thing to keep in mind is that you should perform all of your tests from the same location. This reduces the chance of abnormal network conditions such as a faulty switch or congested link in addition to any changes to routers or firewalls along the path.
If packet loss is still being measured, it may be time to investigate whether your problem is caused by issues with the ISP, router/firewall, cable modem, DPC/modem, or even a bad NIC on one or both source and destination machines! Eventually, you’ll come across a solution that works for you! Good luck.
