iperf

Ping tells you how quickly a single small message comes back, but it says nothing about how much data you can actually push through a path. To learn that, you need to try moving a lot of data and see how fast it goes — like timing how quickly you can pour a full bucket of water through a pipe, rather than just dropping in one dye marker. iperf is the standard tool for exactly this: an active measurement of achievable throughput between two machines you control.

It works as a pair. You run iperf in server mode on one machine and in client mode on the other, pointed at the server. The client then sends data as fast as the path will let it for a fixed time, by default a few seconds, and both ends report the rate achieved in bits per second. With TCP, iperf measures the throughput a real, well-behaved TCP connection can sustain — including the effects of congestion control, the round-trip time, and the bandwidth-delay product. With UDP, you instead set a target sending rate and iperf reports how much arrived, the loss, and the jitter, which is useful for testing whether a link can carry, say, a video stream.

Be honest about what iperf is and is not telling you. It measures throughput, the rate you actually achieved under these conditions, not bandwidth, the link's raw capacity — and the result depends heavily on the path, the time of day, the TCP settings, and the CPU of the two endpoints. Because it deliberately tries to saturate the path, iperf is disruptive: running it on a production link can briefly starve real users, so it is best run on idle links or in a maintenance window. It also requires you to control both ends, which is why it measures the network between your machines, not the speed of some arbitrary website.