You are here: Duckware » UDP Test
UDP Test
Test upload 'buffer size', 'bursting', and 'latency'
Works on ANY platform supporting Java

Download/Extract: Download, extract all files contained within this ZIP into a temp folder (eg: C:\udptest), and get started by reviewing below. NOTE: For best test results, this program must be run on computers with an Ethernet connection to the Internet (avoid wireless connections) -- and on Internet connections that are idle (contention will alter results). Make sure to run the 'Server' on a fast download Internet connection (much faster than the 'client computer' upload speeds being tested). Designed to test and measure Internet upload connections below 50 Mbps (not Gigabit connections).

What is measured: The UDP test program was designed to test the upload characteristics of an Internet connection. Namely, to test and measure:
  1. modem upload buffer size
  2. modem upload bursting speed (more details)
  3. upload latency caused by a filled upload buffer (BufferBloat)
Run a 'Server' somewhere out in the Internet: The first step is to run a 'Server' somewhere out in the Internet. This can be anywhere -- a public server, a friend's home, etc:
java -cp udptest.jar Server <client-ip-address>:<port>
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:
java -cp udptest.jar Client <server-ip-address>:<port> <num-packets> <mstime>
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:
java -cp udptest.jar Server localhost:5000
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):
java -cp udptest.jar Client <server-ip-address>:5000 50 1
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):
Sent: 140 packets (140000 bytes) in 2.1ms (533.33 Mbps)
Recv: 138 packets (138000 bytes) in 45.8ms (24.1 Mbps)
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.

All packets are sent to the modem incredibly fast (in just milliseconds on Gigabit Ethernet), and are either buffered, or discarded (when the modem buffer is full). The size of that modem buffer is what is being measured (by the Server).
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:
java -cp udptest.jar Client <server-ip-address>:5000 100 1
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:
Sent: 100 packets (100000 bytes) in 1.5ms (533.33 Mbps)
Recv: 100 packets (100000 bytes) in 19.3ms (41.3 Mbps)
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.

All packets are sent to the modem incredibly fast (in just milliseconds on Gigabit Ethernet), and then egress to the Internet at some slower rate. That egress rate is what is being measured (by the Server).
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'.
RTT: 14.9 -> 115.3
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).

The amount of latency measured via this RTT method should be incredibly close to the latency you can calculate by knowing the modem buffer size and egress Mbps rate. A little more complicated when there is upload bursting, but otherwise a very straightforward calculation.
Java: Visit 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
java -cp udptest.jar Client <server-ip-address>:<port> 300 200 300 1800 30
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:
ISP Speed Modem
DownUp Model Buffering Burst
Mediacom FL 130 12.0 CGA4236 2,000,000 80.0
Comcast FL 470 23.6 CGM4140COM 860,000 47.9
Spectrum/Charter NC 500 21.0 ES2251 700,000 no
Spectrum/Charter NC 115 11.5 TM1602A 500,000 no
Comcast GA 235 11.8 CM1000 440,000 no
Comcast FL 400 12.0 TG3482G (XB6) 400,000 40.0
Spectrum/Brighthouse FL 220 12.0 CM1000 395,000 no
Spectrum CA 128 24.3 E31U2V1 345,000 no
CenturyTel UT 30 2.0 C1100Z 320,000 no
Spectrum/Brighthouse FL 111 11.0 SB6141 250,000 44.5
Atlantic Broadband/Metrocast NH 250 21.1 SB6183 160,000 36.7
Atlantic Broadband/Metrocast NH 90 5.4 SB6183 150,000 45.3
Comcast/Adelphia MD 360 12.0 SB6183 138,000 42.8
Comcast GA 235 12.0 SB6183 138,000 32.9
Comcast GA 456 22.4 SB6183 140,000 68.0
Comcast MD 230 6.0 TG1682G 90,000 41.8
Spectrum/Brighthouse FL 80 7.0 SB6183 80,000 20.0
Spectrum/RoadRunner NY 300 11.6 DVW32CB 75,000 16.0
Hotwire Communications FL 280 86.0 ONTxxx 32,000 8.25
Mediacom FL 70 12.0 TC8717 (na) 18.0
Mediacom FL 135 12.0 CODA4589 (na) no
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