|You are here: Duckware » UDP Test|
Test modem 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).
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.
Test Results: Here are test results obtained from various locations:
This document is Copyright © 2020 Jerry Jongerius