0

iperf2 (version 2.0.9) reports latency in its output as shown below.

Is it a two-way latency or one-way latency measurement ?

Server listening on UDP port 5001 with pid 5167 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default)

[ 3] local 192.168.1.102 port 5001 connected with 192.168.1.101 port 59592 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Latency avg/min/max/stdev PPS [ 3] 0.00-1.00 sec 122 KBytes 1.00 Mbits/sec 0.063 ms 0/ 6254 (0%) 659.932/659.882/660.502/ 8.345 ms 6252 pps [ 3] 1.00-2.00 sec 122 KBytes 1.00 Mbits/sec 0.020 ms 0/ 6250 (0%) 660.080/659.919/666.878/ 0.110 ms 6250 pps [ 3] 2.00-3.00 sec 122 KBytes 1.00 Mbits/sec 0.020 ms 0/ 6250 (0%) 660.113/659.955/660.672/ 0.047 ms 6250 pps [ 3] 3.00-4.00 sec 122 KBytes 1.00 Mbits/sec 0.022 ms 0/ 6250 (0%) 660.153/659.994/660.693/ 0.047 ms 6250 pps [ 3] 4.00-5.00 sec 122 KBytes 1.00 Mbits/sec 0.021 ms 0/ 6250 (0%) 660.192/660.034/660.617/ 0.049 ms 6250 pps

Hanamantagoud
  • 47
  • 3
  • Got the answer from the link https://www.reddit.com/r/networking/comments/8j3rky/iperf_enhanced_reports_for_udp_latency/. Its one-way latency. – Hanamantagoud Sep 15 '20 at 13:53

1 Answers1

0

It's one-way which requires the clocks to be synchronized to a common reference. You may want to check in to Precision Time Protocol. Also, tell your hosting provider that you want better clocks in their data centers. The GPS atomic clock is quite accurate and the signal is free.

There is a lot more work going on with iperf 2.0.14 related to TCP write to read latencies. Version 2.0.14 will enforce the use of --trip-times on the client before any end/end or one way latency measurements are presented. This way the user tells iperf that the systems have their clocks synchronized to the accuracy which the user deems as sufficient. We also produce a Little's law inP metric along with network power. See the man pages for more. The hope is to have iperf 2.0.14 released by early 2021.

[rjmcmahon@localhost iperf2-code]$ src/iperf -s -i 1
[  4] local 192.168.1.10%enp2s0 port 5001 connected with 192.168.1.80 port 47420 (trip-times) (MSS=1448) (peer 2.0.14-alpha)
[ ID] Interval        Transfer    Bandwidth       Reads   Dist(bin=16.0K)     Burst Latency avg/min/max/stdev (cnt/size) inP NetPwr
[  4] 0.00-1.00 sec  1.09 GBytes  9.34 Gbits/sec  18733    2469:2552:2753:2456:2230:2272:1859:2142     2.988/ 0.971/ 3.668/ 0.370 ms (8908/131072) 3.34 MByte 390759.84

Note: For my testing during iperf 2 development, I have GPS disciplined oven controlled oscillators from spectracom in my systems. These cost about $2.5K each and require a GPS signal.

rjmcmahon
  • 324
  • 1
  • 3
  • Thank you rjmcmahon for the answer – Hanamantagoud Sep 23 '20 at 11:26
  • Is there any other tool which doesn't depend on timestamp ? iperf2 is showing negative latency for me recently. When we check the timestamp of nodes , they are synced using NTP. The time diff between nodes , its in micro second. – Hanamantagoud May 28 '21 at 09:30
  • It isn't possible to measure one way delay (OWD) without timestamps and clock sync. NTP over a network is mostly for humans. PTP and a common reference, e.g the GPS atomic clock, is required. Some links: Computer clocks about as good as mechanical watch: https://www.pcworld.com/article/2891892/why-computers-still-struggle-to-tell-the-time.html DIY stratum 1 server: https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html – rjmcmahon May 29 '21 at 17:59