Update IPerf

Status
Not open for further replies.

Mirfster

Doesn't know what he's talking about
Joined
Oct 2, 2015
Messages
3,215
Sorry if this has been asked before, but I did a forum search real quick and didn't see anything pertaining to it.

Anyways running FreeNas 9.10 I just noticed that iperf 2.0.5 is installed and is pretty old
Code:
[root@ASC-FN01] ~# iperf -v
iperf version 2.0.5 (08 Jul 2010) pthreads


Per: https://iperf.fr/iperf-download.php#freebsd there are several newer versions available:
Code:
FreeBSD 64bits (AMD64) by Bruce A. Mah

    iPerf 3.1.2 - Pkg package (1 fev 2016 - 84.6 Kio)
    iPerf 3.0.11 - Pkg package (9 jan 2015 - 77.0 Kio)

FreeBSD 32bits FreeBSD 32bits (i386) by Bruce A. Mah

    iPerf 3.1.2 - Pkg package (1 fev 2016 - 85.3 Kio)
    iPerf 3.0.11 - Pkg package (9 jan 2015 - 77.8 Kio)


Any chance on getting the newer versions included? I know that IPerf3 is not backwards compatible with IPerf v2.x but am just asking. :)
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
iperf 3 is different than iperf 2.

iperf 2 is currently at 2.0.8 but I'm not aware of any pressing reason to update it. There's benefits to sticking with iperf 2 because that's a little more widely used.
 

Mirfster

Doesn't know what he's talking about
Joined
Oct 2, 2015
Messages
3,215
Agreed, just happened to notice when I was testing from a Windows 7 machine. Downloaded the 3.1.2 version and got squat; then I realized I had to check the version in FreeNas. Grabbed the 2.0.8B version for Win 7 and got it working. Was just curious since most people may make the same mistake and grab what would be considered a "newer" version but not understand why it doesn't work.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Agreed, just happened to notice when I was testing from a Windows 7 machine. Downloaded the 3.1.2 version and got squat; then I realized I had to check the version in FreeNas. Grabbed the 2.0.8B version for Win 7 and got it working. Was just curious since most people may make the same mistake and grab what would be considered a "newer" version but not understand why it doesn't work.

That's probably true for new users, but those of us who use it professionally are probably still annoyed that someone felt it necessary to make a third version, and since we've got the second version installed everywhere, ... well anyways, mess.
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,175
The iX party line is that they're sticking with iperf 2, last I heard.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
The iX party line is that they're sticking with iperf 2, last I heard.

Yeah, not surprising since it is by far the more common one, in my experience. iperf 3, an example of fixing a problem that didn't exist.
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,175
My only complaint about iperf 2 is that it uses active wait on the server, which is annoying if you forget to kill the server.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Ah, I'm familiar with this situation. iperf3 isn't in FreeNAS because it's not widely used, hasn't really been well accepted by the networking community, and doesn't really solve problems that existed in iperf2. iperf2 really is "the industry standard" for network throughput testing. Some people have reported very odd and unexpected behavioral issues with iperf3, which haven't been worked out (and allegedly I've heard that some can't really be fixed because of some poor design choices with iperf3 without making an iperf4).

"If it ain't broke, don't fix it" seems to be the answer here. ;)
 
Joined
Jun 2, 2016
Messages
13
iperf 2.0.9 now honors the -t value so the listener/server will exit if that's set.

https://sourceforge.net/projects/iperf2

here's a list of things vs 2.0.5
  • Fix portability, compile and tested with Linux, Win10, Win7, WinXP, MacOS and Android
  • Require -u for UDP (-b no longer defaults to UDP)
  • Improved performance
  • Enhanced reporting with -e
  • Support smaller report intervals (5 ms or greater)
  • Support SO_RCVTIMEOUT for server reports regardless of no packets
  • Support SO_TIMESTAMP for kernel level packet timestamping
  • Support end/end latency in mean/min/max/stdev format (UDP) (-e required)
  • (assumes client and server clocks synched, e.g by Precision Time Protocol)
  • Add local port to bind support (-B option) using colon as separator
  • (e.g. iperf -c 192.168.100.100 -B 192.168.100.10:6001)
  • Support TCP rate limited streams (via the -b) using token bucket
  • Support packets per second (UDP) via pps as units, (e.g. -b 1000pps)
  • Display PPS in both client and server reports (UDP) (-e required)
  • Support realtime scheduler as a command line option (--realtime or -z, assumes proper user privileges)
  • Improve client tx code path so actual tx offered rate will converge to the -b value
  • Improve accuracy of microsecond delay calls (in platform independent manner)
  • (Use of Kalman filter to predict delay errors and adjust delays per predicted error)
  • Display target loop time in initial client header (UDP)
  • Fix final latency report sent from server to client (UDP)
  • Include standard deviation in latency output
  • Suppress unrealistic latency output using (-/-/-/-)
  • Support SO_SNDTIMEO on send so socket write won't block beyond -t (TCP) or -i
  • Use clock_gettime if available (preferred over gettimeofday())
  • TCP write and error counts (TCP retries and CWND for linux) (-e required)
  • TCP read count, TCP read histogram (8 bins) (-e required)
  • TCP RTT and CWND values in client reports (-e required, Linux only, RTT units microseconds)
  • Added support for -t on the Server (Listener) so servers/listener can be set to timeout and exit
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,175
  • Improve accuracy of microsecond delay calls (in platform independent manner)
  • (Use of Kalman filter to predict delay errors and adjust delays per predicted error)
That sounds like massive overkill. I never would've imagined a reason to use a Kalman filter in iperf, of all places.
 
Joined
Jun 2, 2016
Messages
13
That sounds like massive overkill. I never would've imagined a reason to use a Kalman filter in iperf, of all places.

There is an option to disable during compile (though the CPU cost, being a Kalman, is negligible.) We have some real-time requirements where getting the IPG (inter packet gap) as accurate as possible has been helpful. Of course, one's mileage will vary as do the requirements needs of such a tool.

Bob
 

philhu

Patron
Joined
May 17, 2016
Messages
258
Any chance of getting 2.0.9? It would fix alot of thread problems in 2.0.5
 

philhu

Patron
Joined
May 17, 2016
Messages
258
Ok. But it should be easy for a FreeBSD user to compile 2.0.9. Since source is available and does not have incompatible api or source changes, according to iperf docs

I did notice iperf3 versions there. So can this be loaded into FreeNAS with an pkg add? They can coexist can't they?
 
Last edited by a moderator:

Mirfster

Doesn't know what he's talking about
Joined
Oct 2, 2015
Messages
3,215
Should be able to as well as submit to FreeBSD. Don't think FreeNAS will include anything that FreeBSD doesn't.

Haven't tried iperf3 so wouldn't know. Of course adding stuff to the OS is not really recommended either. ;)
 
Joined
Jun 2, 2016
Messages
13
Should be able to as well as submit to FreeBSD. Don't think FreeNAS will include anything that FreeBSD doesn't.

Haven't tried iperf3 so wouldn't know. Of course adding stuff to the OS is not really recommended either. ;)

Just a head's up. A goal of 2.0.9 is first not to break the cli and output. This is needed because we have a lot of automated scripts and we don't want those to be impacted by an iperf upgrade. That's why all new output requires the -e (for enhanced reports.)

The second goal of maintaining 2.0.9 and 2.0.5 interoperability hasn't been as critical for us because when we upgrade we do both the client and the server together. Therefore, iperf 2.0.5 and iperf 2.0.9 interoperability has had limited testing. Sounds like we may want more 2.0.5 and 2.09 interoperability testing. Let me know if this is correct or not.

Thanks,
Bob
 

philhu

Patron
Joined
May 17, 2016
Messages
258
Yes. Especially if 2.0.5 is going to be last version on Freebsd for a while. I did run into an issue with 2.0.5 on Freenas and 2.0.9 on windows. The bidirectional setting, --dual?? (Dont remember off top of my head) crashed the freeNAS server side when it tries to switch to send from rcv
 
Joined
Jun 2, 2016
Messages
13
Yes. Especially if 2.0.5 is going to be last version on Freebsd for a while. I did run into an issue with 2.0.5 on Freenas and 2.0.9 on windows. The bidirectional setting, --dual?? (Dont remember off top of my head) crashed the freeNAS server side when it tries to switch to send from rcv

That wouldn't surprise me as I don't think we use -D (dual) as part of our wi-fi testing. That's also an area of code that I may not have maintained interoperability. I'll plan to add a FreeBSD system soon and see if I can recreate the issue.

As a side note, iperf3 replaced the -R with reverse mode testing. For 2.0.5 -R removes the service on the server. This reverse mode testing seems useful but using -R will break command line compatibility. I'm considering adding support for reverse mode testing but will probably on due so using a long option (e.g. --reverse)

Bob
 

philhu

Patron
Joined
May 17, 2016
Messages
258
That would be cool!

FreeNAS is all about network speed! And testing on it is good!
 
Status
Not open for further replies.
Top