You are here: Duckware » UDP Test |
Test upload 'buffer size', 'bursting', and 'latency' Works on ANY platform supporting Java
What is measured: The UDP test program was designed to test the upload characteristics of an Internet connection. Namely, to test and measure:
To automatically punch through a NAT firewall, must specify the IP address of the one client to support (otherwise, specify 'localhost' for the ip address and configure a 'port forward' firewall rule to support multiple clients). The port number provided is automatically assigned to the 'Server'. The port number provided 'plus one' is automatically assigned to clients.On the Internet connection to test, run a 'Client': Next, run a 'Client' on the Internet connection to test, using this command line: The client will then output (to the server) the number of (1000 byte) packets, spread over the "mstime" provided, and report back the number of packets the server actually received (and time frame received, with computed Mbps speed). NOTE: The udptest tool is designed to test the network (like the router and mode; not the PC end points). As such, the both the client and server should be connected 'as fast as possible' to the network. Gigabit Ethernet is recommended. Example: Run a server: Here is example of running the server behind a NAT with a firewall rule forwarding port 5000 to the computer running the server, to support multiple clients: Measure upload buffer size: Repeat the test below over and over, each time varying/increasing the number of packets sent out (in blue), until a 'breaking point' of packet loss is reached (example in red further below): The 'breaking point' is where packet loss starts to occur, as seen in red below (as opposed to always receiving all packets that were sent out): Repeat the test to confirm that the packet loss was the result of filling the modem buffer (and not just random loss out in the Internet). It is fairly common to see a modem buffer size somewhere between 100,000 and 150,000 bytes (the 138,000 result above was for an Arris SB6183 cable modem on Comcast's network). On the client computer, you should see the packets sent out in just a couple of milliseconds (the 2.1ms above). If you do not see a relatively small ms time, try another (faster) client computer.Measure upload bursting speed: To measure upload bursting speed (tech article), send out a number of packets less than the modem buffer size measured in the step above: and then take note of the received Mbps speed. There is 'upload bursting' only when the Mbps result (in blue below) is well above the known tested and known Internet upload speed: If the speed matches (or is close to) the known Internet upload speed (Google Fiber Speed Test), the Internet modem likely does NOT have 'upload bursting'. The example above (41 Mbps) was obtained on an Internet connection with a known sustained 12 Mbps upload speed. Upload bursting happens when the modem allows a small number of initial packets to egress to the Internet at a speed much faster than rated (sustained) Internet upload speed.Measure BufferBloat upload latency: Send just under the number of packets that causes packet loss and take note of the RTT output line. If this RTT number is zero, the RTT measurement packet was lost (most likely a modem buffer overrun) -- so back off the number of packets sent by one (and repeat) until a non-zero RTT measurement is obtained. The result is the RTT times for the 'modem buffer empty' vs the 'modem buffer full'.
This measurement 'works' by intentionally filling the modem upload buffer to the breaking point and then adding on one final test packet, whose RTT time is then measured. The test packet must sit and wait in the modem buffer for all prior packets to egress first -- and that 'waiting' is what adds significant latency (measured by the Client when the RTT packet is echoed back).Java: Visit java.com if you don't already have the Java VM installed on your computer. To test if your computer has a Java VM installed, run the "java -version" command (valid output means yes, unrecognized command means no). Donate: If you find this program helpful, please support it with a donation. Advanced: A square-wave of UDP packets: The 'Client' command line allows for an optional second 'num-packets' and 'mstime' and 'repeat' value, which allows for a square wave of UDP to be produced. For example, this command line sends out 300 packets in 200 milliseconds, then 300 packets in 1800 milliseconds -- all repeated 30 times, which results in a 'square wave' of UDP packets: Test Results: Here are test results obtained from various locations: Interesting Arris chat answer RE buffer sizes: "The upload buffer (for UDP) in the ARRIS SURFboard SB6183 anywhere from around 128K to 150K, depending upon the ISP. This variation is almost certainly due to the fact that DOCSIS allows each ISP to customize buffer sizes in their network." The Arris SB6183 used to be the modem I used everywhere. But no longer! The buffer size in that modem is just too small, and causes problems (packet loss) for Ring cameras, and other devices -- all due to inappropriately small buffering.Hotwire Communications: An unexpected result is that Hotwire Communications in Tallahassee FL has an incredibly small amount of buffering and reverse upload bursting -- upload speed starts out slow and takes time to ramp up!
This document is Copyright © 2020-2024 Jerry Jongerius
|