 |
| You are here: Duckware » FastPing |
|
(test Mbps speed to/from a device with NO software on the test device)
FastPing: FastPing is a network speedtest tool written in Java and packaged as an EXE for convenience, utilizing ICMP pings sent at a rate you specify. When a large-sized ping is sent at a fast rate to a device being tested, this allows you to measure the Mbps network speed and reliability to that device without installing any software on the device. Great for testing connectivity to lower end IoT devices like Wi-Fi cams, etc. Internet Upload speed: Use a large ping size with TTL of your first Internet hop to obtain an estimate of your Internet connection upload speed: Some routers don't like pings sent too fast -- in that case change the ms time from '0' to '1000' one second: A warning: Some cable modems support 'upload bursting', so this test will measure that faster speed next section. Cable Modem Upload bursting: Often times modems allow a small amount of data to be uploaded at a bitrate much faster than the maximum sustained bitrate a 12 Mbps upload connection may allow bursting up to 40 Mbps. Details. An easy way to see this 'fast burst' and then 'back off' is to upload a bunch of data at ever increasing speeds. Run this command, altering "100" to faster speeds 90,80,...10: Most modems work fine with a large "65000" byte ping but some may not. Also, use caution using the results from this test because I have seen some modems treat ICMP differently than other traffic like UDP. Is your 'Modem to ISP' link reliable?: Use "tracert -d 1.1.1.1" to find the first IP address, or hop, past your modem / router. The goal is to find the IP address of the first Internet hop just past your modem. Then use the following fastping command to probe the reliability of your Internet connection to that 'first hop' IP address: With a reliable Internet connection, there should be NO lost packets -- none. But if you consistently see lost packets, than contact your ISP. I was once at a rental house that was seeing 2% to 3% packet loss all the time. The Internet connection was horrible and the root cause was a very poor connection from the cable modem to the CMTS Wikipedia. Network stress test / reliability: Send out a ton of small pings every 2 milliseconds. On Ethernet, the expectation is no lost packets. On great Wi-Fi, there will be no lost packets. But, in general, expect Wi-Fi to have some packet loss from this stress test. Test Wi-Fi Camera connectivity: Send large pings to the IP address of your Wi-Fi cam to check combined average for both upload and download Mbps speed: Is 'slow Wi-Fi' to a device due to poor Wi-Fi (or the device)? You 'fastping' with large ping sizes a device and sometimes notice significant slowdowns. Is that caused by poor Wi-Fi, or caused by the device itself? One way to find out is to ping TWO devices interleaved at the same time. If they both 'have trouble', then poor Wi-Fi is likely to blame. But if one device pings fast, and the second device pings slow, the problem is not Wi-Fi. Reduce ping size if all pings fail: If all pings are failing, the device you are testing likely does not like the 'large' ping sizes. Use the -l:size command line option to select a smaller size. Start at a very small size like 1000 and ramp until you reach a failure point and then back off a little from that. But a warning: As you decrease the ping size, the relative size of the unmeasured 'network overhead' increases, making the resulting Mbps speed measured less accurate. Slow down the pings if only some 'later' pings fail: If some 'later' pings are failing first pings work, the device you are testing may not like the fast rate of pings. Slow down the rate of pings. Instead of 'back-to-back' with -ms:0, slow down the pings using -ms:250 or even larger/slower. Why the ping size default is "62500": To also allow 'mental math' to quickly determine the resulting Mbps. All of the math simplifies down to dividing ms reponse time into 1000 to obtain Mbps. For example, a large 62500 ping to a host that also responds with a ping reply in 10ms is 1000/10=100, or 100 Mbps. Here is the full math: Also, a size of 62500 is large enough to make the unmeasured 'network overhead' relatively small, making the calculated Mbps very close a slight underestimate of actual Mbps. This works great for Wi-Fi devices on 'slower' links. It is NOT designed to accurately measure Gigabit speeds. Large pings ARE fragmented (and therefore, a great network stress test): Large pings are designed to stress test your networking environment. A large ping must be split into many IP fragments and each fragment send individually, which are then recombined at the other end into a single ping request and the same thing happens to the ping reply. If even a single fragment is lost either way, the entire ping will fail. This makes large pings a GREAT network stress and reliability test. Each large 62500 byte ICMP ping is actually sent as 43 IP fragments over Ethernet with MTU=1500.IP Fragmentation math: IP header overhead is 20 bytes. ICMP header overhead is 8 bytes. The first IP fragment can send 1472=1500=20-8 bytes of ping payload. All other subsequent IP fragments in the ping can send 1480=1500-20 bytes of ping payload. So with a 62500 byte ICMP large ping, the first IP fragment sends 1472 bytes, the next 41 IP fragments each send 1480 bytes, and the last fragment sends 348 bytes, for a total of 62500 bytes over 43 IP fragments.Maximum size: The realistic maximum size for a ping is often 65,507 bytes, as that results a packet with 65,535 bytes -- 8 ICMP header + 20 IP header + 65507 ping data = 65535. Donate: If you find this program helpful, please support it with a donation. Manually running 'large pings' on Windows/Linux Windows large ping: To test the 'large ping' concept using the ping program built into Windows: Linux large ping: To test the 'large ping' concept using the ping program built into Linux: MacOS large ping: MacOS limits ping size to MTU size, so MacOS does NOT support large pings. A deep dive into 'large pings' failing on some TP-Link routers I was testing a TP-Link AX80 router over Wi-Fi and every other large ICMP ping was failing Ethernet worked fine. A Wireshark capture pinpointed the issue immediately. The TP-Link router was sending ICMP reply fragments 'out of order', but strangely, only sometimes. Then Windows would fail to reassemble the ping reply: (a) only when the ICMP reply fragments were out-of-order, and (b) only when there were more than 32 fragments So, this is ALSO a Windows bug caused by TP-Link router strangeness! A long time later, I stumbled upon the Windows reassemblyoutoforderlimit setting that was causing this: which can be viewed along with many other settings by entering this command from inside a Command Prompt: The solution: The workaround 'solution' is to increase the Windows 'reassembly out of order limit' from 32 to 45 fragments. Please note that this command must be run as an administrator from inside a Command Prompt: The change takes place immediately no need to reboot. However, after a system reboot, the old limit may be set to 32 again.
This document is Copyright © 2020-2025 Jerry Jongerius
|