A single Python file end-to-end latency testing tool based on UDP 📈.

Support both one-way and round-trip latency measurement:

• udp_latency.py measures one-way latency.
• udp_rrt.py measures round-trip latency. (both with same arguments)

Compare with existing latency measuring tools.

python3 udp_latency.py -c -f/m <frequency / bandwidth> -n <packet size> -t <running time> --ip <remote ip> --port <remote port> --verbose <bool> --sync <bool>

python3 udp_latency.py -s -b <buffer size> --ip <remote ip> --port <local port> --verbose <bool> --sync <bool> --save <records saving path>

⚠️ Udp-latency (one-way) requires precise synchronization (same clock time) between server and clients. The basic idea for my implementation is from IEEE PTP protocol.

In the first 10 seconds before measurement, PTP events are exchanged per second to calculate time offset between the server and clients. To avoid the impact on the experimental traffic, it stops sending PTP messages during the experiment and neglects the time drifting.

Udp-rrt doesn't rely on synchronization.

⚠️ This method will slightly damage the periodicity. (Small jitter contains with this additional bandwidth optimization)

Due to the non-deterministic delay in `socket.sendto()` system call, it is difficult to maintain a constant sending bandwidth/frequency. For example, you want to send flow in 5 Mbits with `-m` argument (for a 100 byte packet in 1 Gbs linkspeed, you call `socket.sendto` every 2.5 us in Python interpreter), however, the sending speed can be only 3 Mbits when there is an around 1.67 us delay in `socket.sendto()` system call. Furthermore, this delay can be different using kernel scheduling policy and system workload making it hard to bound or estimate (See the following figure about the delay measurement).

To alleviate this problem here, this code uses a greedy method to adjust sending frequency dynamically (like PID control):

$$ NewFrequency = \frac{ExpectedFrequency}{DecayedRate}, ExpectedFrequency = \frac{CurrentFrquency \times RunningTime}{RemaingTime}, DecayedRate = \frac{CurrentFrequency}{Global Frequency} $$

Where $CurrenctFrequency$ is the accumulated frequency from the program beginning to the current time. $GlobalFrequency$ is the frequency user set with -f or -m argument. $RunningTime$ and $RemainingTime$ are the time from the programming beginning time and time to the programming ending time defined by -t argument respectively.

During the local test through 127.0.0.1, the gap between realistic and expected bandwidth is bounded within 1%, the difference can be 30% without dynamic adaption.

Feel free to contact me at [email protected]