I was running an UDP test and I noticed that the jitter value was way too high, is something not initialized properly in iperf3 source code? The connection between client and server is very good.
Maybe the reason for high jitter was that prev_transit is not initialized to zero, but I am not sure.
How jitter should work: http://toncar.cz/Tutorials/VoIP/VoIP_Basics_Jitter.html
Client:
[ 4] local 10.131.136.133 port 49402 connected to 10.131.138.232 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 16.0 KBytes 131 Kbits/sec 2
[ 4] 1.00-2.00 sec 8.00 KBytes 65.5 Kbits/sec 1
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total
Datagrams [ 4]
0.00-2.00 sec 24.0 KBytes 98.2 Kbits/sec 63.064 ms 0/3 (0%)
[ 4] Sent 3 datagrams
iperf Done.
Server:
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 2 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 16.0 KBytes 131 Kbits/sec 67.261 ms 0/2 (0%)
[ 5] 1.00-2.00 sec 8.00 KBytes 65.5 Kbits/sec 63.064 ms 0/1 (0%)
[ 5] 2.00-2.04 sec 0.00 Bytes 0.00 bits/sec 63.064 ms 0/0 (-nan%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-2.04 sec 0.00 Bytes 0.00 bits/sec 63.064 ms 0/3 (0%)
CPU Utilization: local/receiver 0.0% (0.0%u/0.0%s), remote/sender 1.9% (0.3%u/1.8%s)
iperf 3.1
I'm guessing you are the same person who filed this issue in the iperf3 issue tracker because the wording of this question and the one in the issue tracker are almost identical:
https://github.com/esnet/iperf/issues/672
I answered there that you had too few packets per measurement interval to actually compute the jitter in a meaningful way. I suggested that you send at a higher bitrate to get more data points to measure the jitter. Also you should use a version of iperf3 that is 3.2 or newer because of improvements in the timing of sending packets.