iperf3 module on pico-w: KeyError: end_time

[graeme-winter]

>>> iperf3.client("192.168.1.249")
CLIENT MODE: TCP sending
Connecting to ('192.168.1.249', 5201)
Interval           Transfer     Bitrate
  0.00-1.00   sec   655 KBytes  5.36 Mbits/sec
  1.00-2.00   sec   639 KBytes  5.23 Mbits/sec
  2.00-3.00   sec   656 KBytes  5.38 Mbits/sec
  3.00-4.00   sec   669 KBytes  5.48 Mbits/sec
  4.00-5.00   sec   669 KBytes  5.48 Mbits/sec
  5.00-6.00   sec   666 KBytes  5.45 Mbits/sec
  6.00-7.00   sec   686 KBytes  5.62 Mbits/sec
  7.00-8.00   sec   642 KBytes  5.25 Mbits/sec
  8.00-9.00   sec   680 KBytes  5.56 Mbits/sec
  9.00-10.00  sec   555 KBytes  4.56 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  0.00-10.00  sec  6.36 MBytes  5.34 Mbits/sec  sender
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "iperf3.py", line 491, in client
  File "iperf3.py", line 150, in report_receiver
KeyError: end_time

[graeme-winter]

Suspect that this is just a race condition, where the packets are being handled less quickly than a usual iperf3 implementation & so one arrives out of order

[graeme-winter]

(all this is assuming the iperf3.mpy from mip install is derived from the code in micropython-lib)

[jimmo]

Suspect that this is just a race condition, where the packets are being handled less quickly than a usual iperf3 implementation & so one arrives out of order

Unless I'm missing something silly, that line is computing dt which is never actually used. It would fail on the next line anyway though.

I'm curious though -- I've used iperf3 a fair bit (both with micropython and other iperf3 implementations at the other end) and never seen this error. And weirdly stats["streams"][0] is clearly still a dictionary, so clearly it received something from the other end, it just happened to be missing these keys. @graeme-winter Would it be possible to add a try/except KeyError and print stats["streams"][0] to see what the other end sent?

Also, what is the other iperf3 implementation that it's talking to?

(all this is assuming the iperf3.mpy from mip install is derived from the code in micropython-lib)

That's exactly right.

[graeme-winter]

Server end is iperf3 on macOS

iperf 3.1.3
Darwin silver-surfer-2.lan 20.6.0 Darwin Kernel Version 20.6.0: Thu Mar  9 20:39:26 PST 2023; root:xnu-7195.141.49.700.6~1/RELEASE_X86_64 x86_64
Optional features available: sendfile / zerocopy

{'errors': 0, 'packets': 0, 'bytes': 6774200, 'jitter': 0, 'id': 1, 'retransmits': -1}

is your response packet - I also note that the iperf3 -s process is left in a "funny state"

[graeme-winter]

Additional - with iperf3 -s running on a linux system (raspian) it works cleanly ->

>>> iperf3test.client("192.168.1.179")
CLIENT MODE: TCP sending
Connecting to ('192.168.1.179', 5201)
Interval           Transfer     Bitrate
  0.00-1.00   sec   677 KBytes  5.54 Mbits/sec
  1.00-2.00   sec   772 KBytes  6.31 Mbits/sec
  2.00-3.00   sec   783 KBytes  6.41 Mbits/sec
  3.00-4.00   sec   725 KBytes  5.94 Mbits/sec
  4.00-5.00   sec   696 KBytes  5.70 Mbits/sec
  5.00-6.00   sec   747 KBytes  6.11 Mbits/sec
  6.00-7.01   sec   711 KBytes  5.82 Mbits/sec
  7.01-8.01   sec   752 KBytes  6.16 Mbits/sec
  8.01-9.01   sec   744 KBytes  6.09 Mbits/sec
  9.01-10.00  sec   753 KBytes  6.19 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  0.00-10.01  sec  7.19 MBytes  6.02 Mbits/sec  sender
  0.00-10.76  sec  7.19 MBytes  5.60 Mbits/sec  receiver

so suspect API differences...

[dpgeorge]

I found a relevant comment in the iperf source code:

                                 * We have to handle the possibility that
                                 * start_time and end_time might not be
                                 * available; this is the case for older (pre-3.2)
                                 * servers.

So, that's the issue.

[dpgeorge]

Fixed by 01ab7ba