Kitz Forum

Computer Software => General software => Topic started by: Weaver on October 19, 2019, 08:43:52 AM

Title: iPerf III - The Reckoning
Post by: Weaver on October 19, 2019, 08:43:52 AM

I have been running some tests with the iPerf speed tester feature that is built into the iOS net toolbox app which I wrote a review of a while back. The servers that I have used are in France and the USA - the latter being pretty useless for a uk user.
—
    ping6.online.net — France?
    Upload sent: 1.78 / received: 1.3
    Download sent: 10.45 / received 9.85
—
    iperf.he.net — USA
    Upload sent: 1.37 / received 1.17
    Download sent: 6.88 / received 5.18
—
In these results, where it talks about sent and received, I presume that is is what it appears to be but if the received count does not match the sent count, then why not ? Is this a home brew TCP-like application, which can count lost packets or retransmissions or both and include them into the totals? If it is a normal application above a normal TCP implementation then it would have to be talking about TCP SDUs’ byte counts and so how could anything that has been sent not be ‘received’? (As it’s a reliable transport.) the only thing I can think of in the latter scenario is that some stuff has not been ‘received’ because the experiment was terminated too soon and there is still stuff in transit or sitting in buffers waiting on lost or withheld ACKs. That would mean that the test is rubbish because it’s far too short a duration and it would be far more accurate if it were longer - for the above reasons and also because of the bad effects of TCP slow start.

You see that these sent vs received counts don’t match up, in fact some are a long way off? So what are we supposed to make out of that?

Title: Re: iPerf III - The Reckoning
Post by: Alex Atkin UK on October 19, 2019, 06:49:02 PM

Packet drops/retries.  A proper implementation of iperf3 should tell you this:

Code: [Select]

Connecting to host 10.7.0.1, port 5201
[  5] local 192.168.1.1 port 42218 connected to 10.7.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.02 MBytes  16.9 Mbits/sec   67   78.8 KBytes       
[  5]   1.00-2.00   sec  1.79 MBytes  15.0 Mbits/sec   38   43.3 KBytes       
[  5]   2.00-3.00   sec  1.97 MBytes  16.5 Mbits/sec   31   81.4 KBytes       
[  5]   3.00-4.00   sec  1.72 MBytes  14.5 Mbits/sec   32   43.3 KBytes       
[  5]   4.00-5.00   sec  1.72 MBytes  14.5 Mbits/sec   39   51.2 KBytes       
[  5]   5.00-6.00   sec  1.72 MBytes  14.5 Mbits/sec   47   70.9 KBytes       
[  5]   6.00-7.00   sec  1.72 MBytes  14.5 Mbits/sec   28   73.6 KBytes       
[  5]   7.00-8.00   sec  1.72 MBytes  14.5 Mbits/sec   67   65.7 KBytes       
[  5]   8.00-9.00   sec  1.97 MBytes  16.5 Mbits/sec   31   70.9 KBytes       
[  5]   9.00-10.00  sec  1.72 MBytes  14.5 Mbits/sec   58   5.25 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  18.1 MBytes  15.2 Mbits/sec  438             sender
[  5]   0.00-10.00  sec  17.6 MBytes  14.7 Mbits/sec                  receiver

Also bear in mind the normal direction for iperf3 traffic is to sent TO the server.  You need to run in reserve mode to test your download.

Code: [Select]

Connecting to host 10.7.0.1, port 5201
Reverse mode, remote host 10.7.0.1 is sending
[  5] local 192.168.1.1 port 42214 connected to 10.7.0.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  6.39 MBytes  53.6 Mbits/sec                 
[  5]   1.00-2.00   sec  6.47 MBytes  54.3 Mbits/sec                 
[  5]   2.00-3.00   sec  6.61 MBytes  55.4 Mbits/sec                 
[  5]   3.00-4.00   sec  6.59 MBytes  55.2 Mbits/sec                 
[  5]   4.00-5.00   sec  6.19 MBytes  51.9 Mbits/sec                 
[  5]   5.00-6.00   sec  6.15 MBytes  51.6 Mbits/sec                 
[  5]   6.00-7.00   sec  6.48 MBytes  54.3 Mbits/sec                 
[  5]   7.00-8.00   sec  6.59 MBytes  55.3 Mbits/sec                 
[  5]   8.00-9.00   sec  6.60 MBytes  55.3 Mbits/sec                 
[  5]   9.00-10.00  sec  5.25 MBytes  44.1 Mbits/sec                 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  63.9 MBytes  53.6 Mbits/sec  117             sender
[  5]   0.00-10.00  sec  63.3 MBytes  53.1 Mbits/sec                  receiver

Also a full implementation has a lot of flags (https://iperf.fr/iperf-doc.php#3doc) to tweak it to your situation.

Title: Re: iPerf III - The Reckoning
Post by: Weaver on October 19, 2019, 11:29:52 PM

I also have a tool with the full thing, a lot of flags. And I can presumably get a version of iPerf for my raspberry pi running Debian Buster ARM64 with any luck too?

Am I correct then in my supposition that iPerf has its own version of TCP (or something more like SCTP) in it? Because otherwise it would not know what the retransmission and drop counts are.

Title: Re: iPerf III - The Reckoning
Post by: ejs on October 20, 2019, 06:28:32 AM

I think it retrieves statistics about the TCP connection from the operating system.

Title: Re: iPerf III - The Reckoning
Post by: Weaver on October 20, 2019, 08:35:24 AM

@ejs which would be much more sane. Otherwise reinventing the wheel.