vienlee / iperf Goto Github PK

Explaination of new feature
An option to set the DSCP field in the IP header for an out-going stream on the 
client side.

On the server side a message if there is any DSCP value.

Justification of new feature

This will allow for a Network admin to make certain that devices between to 
points are not removing the QOS.

Explaination of new feature

Add IPv6 support

Justification of new feature

The end is near!

What steps will reproduce the problem?
1. iperf3 -s
2. iperf3 -c server -u
3.

What is the expected output? What do you see instead?
no idea what to expect. What I get is:
client:
 Connecting to host server, port 5201
 error: Unable to read from stream socket: Connection refused

server:
---------------
Server listening on 5201
---------------
Accepted connection from 10.1.1.2, port 1840
Teh client has unexpectedly close the connection.
---------------

What version of the product are you using? On what operating system?
iperf verion 3.0-BETA4 (2 Aug 2010)
OS: Tru64 v5.1

Please provide any additional information below.
it is very disappointing that UDP does not work. As UDP is unreliable, and 
there is no compensation for packet loss/corruption as compared to TCP, it can 
be extremely useful in diagnosing connections that have problems.
It's a shame you haven't fixed this bug already.

There is an existing parameter to set the qos bits on ipv4
packets.  This should be supported in ipv6 as well.

Richard Hartmann <[email protected]> suggested:

One follow-up: It would be nice if the iperf server could set
DSCP/TOS bits, as well. If ACKs are shaped away, things start
to suck.

I would envision two modes:

1) -S for servers: Set default DSCP value for all outgoing packets

which is overridded by

2) If you receive a packet with DSCP bit vector foo, set the same
for replies to that packet/client.


I'd like to verify that #2 is good netiquette before implementing it.  However, 
#1 should definitely be implemented and be part of the client-server parameter 
exchange.

What steps will reproduce the problem?
1. A measurement for download bandwidth is inaccurate.
2. Which difference between with "-R" and without "-R"?

What is the expected output? What do you see instead?
1. According to the line configuration, I expected the result for Up and 
Download bandwidth is each 1Mbps, 0.5Mbps, But the result was follow as,
(Log is captured on the Server, but client is almost same)
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.64.180.254, port 56738
[  5] local 10.64.84.227 port 5201 connected to 10.64.180.254 port 56739
[ ID] Interval       Transfer     Bandwidth
      Sent
[  5] 0.00-31.05 sec  3.75 MBytes  1.01 Mbits/sec
      Received
[  5] 0.00-31.05 sec  3.50 MBytes   946 Kbits/sec

2. Speaking of the output result both on client and server,
  I cannot recognize the difference between with -R and without -R.
 The result is same.
 I think the results for "Received" had better be removed if without "-R" option.

What version of the product are you using? On what operating system?
iperf-3.04b, CentOS release 5.6

Please provide any additional information below.

Actually I make test-environment asymmetric for up/down link using emulation 
tool like a 'TC' of linux.

Client -- [TC and NAT enabled LinuxBox] --- Server
               Up:1Mbps, Down:0.5Mbps

What steps will reproduce the problem?
1.server execute below command:
  iperf -s -u
2.client execute below command:
  iperf -u -c 10.10.21.188  -i 1 -l 5K -b 1000M -t 10000000 -P 10 -d
3.

What is the expected output? What do you see instead?
when start testing, network card load remaining 96%, but when the tests to 
seven or eight hours after，the network card load down to 0%。I don't know 
why happen it。

What version of the product are you using? On what operating system?
iperf version 2.0.5 (08 Jul 2010) pthreads.
CentOS release 5.2 (Final)

Please provide any additional information below.
 the network card information as belows:
class: NETWORK
bus: PCI
detached: 0
device: eth0
driver: e1000e
desc: "Intel Corporation 82573E Gigabit Ethernet Controller (Copper)"
network.hwaddr: 00:15:17:21:87:e4
vendorId: 8086
deviceId: 108c
subVendorId: 8086
subDeviceId: 348f
pciType: 1
pcidom:    0
pcibus:  3
pcidev:  0
pcifn:  0
-

[root@hh iperf-2.0.5]# ethtool  eth0
Settings for eth0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Full 
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Full 
    Advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: pumbag
    Wake-on: g
    Current message level: 0x00000001 (1)
    Link detected: yes

Any help is appreciated, thanks. :)

Best regards,

chenfangxian

Explaination of new feature

simplify the API by defining a single callback for periodic use.  This can be 
used for intermediate 
results calculation, reporting, etc..

Justification of new feature

What steps will reproduce the problem?
1. iperf3 -s -u
2.
3.

What is the expected output? What do you see instead?
crotwell$ bin/iperf3 -s -u
parameter error: Some option you are trying to set is client only



What version of the product are you using? On what operating system?
3.0b4
linux

Please provide any additional information below.
Same problem with variations on --server and --udp

Docs seem to indicate that -u can be used with -s

By default ARM processors typically use unsigned char for char type. That why 
signed char use must be forced. 
I used arm-linux-gcc-4.2.1 compiler.

Submitting patch for this problem to solve:

diff -r dafbddb0e039 src/Makefile.in
--- a/src/Makefile.in   Mon Aug 20 14:35:58 2012 -0700
+++ b/src/Makefile.in   Wed Sep 05 18:08:55 2012 +0300
@@ -266,7 +266,7 @@

 # Specify the sources and various flags for the iperf binary
 iperf3_SOURCES = main.c
-iperf3_CFLAGS = -g -Wall
+iperf3_CFLAGS = -g -Wall -funsigned-char
 iperf3_LDADD = libiperf.a
 iperf3_LDFLAGS = 

Tested with:
arm-linux-gcc-4.2.1
mipsel-linux-gcc-4.1.2

Explaination of new feature

currently the library code exits rather than signalling an error condition

Justification of new feature

the library shouldn't exit arbitrarily

Implementation Plan

add an error member to the iperf_stream struct to hold per stream errors
define error codes for each distinct error condition
similar to perror in spirit

What steps will reproduce the problem?
1.server execute command - iperf3 -u -s -i 1
2.client execute command - iperf3 -c ip_address -u 
3.re-running command - iperf3 -c ip_address -u after previous execution on 
client causes error "Unable to read from stream socket : Connection refused

What is the expected output? What do you see instead?

should provide output for latency and loss on UDP tests

What version of the product are you using? On what operating system?

Ubuntu server version 11 64bit

Please provide any additional information below.

Explaination of new feature

to allow maximum flexibility implement a callback per state change
this will allow much cleaner separation of library from the tool

Explaination of new feature

make sure all test related i/o uses select

Justification of new feature

cleaner, less error prone

Presently we set the window size to DEFAULT_TCP_BUFSIZE.  

This has two issues:

1. it overrides the system default implicitly
1. it may prevent the system's auto tuning from working

Instead we should set socket_snd_bufsize and socket_rcv_bufsize to zero by 
default (probably in 
iperf_defaults()).  Then when it comes time to set the socket_snd_bufsize and 
socket_rcv_bufsize 
only set it if it isn't zero.

for the present iperf the tool should use -w to set both socket_snd_bufsize and 
socket_rcv_bufsize, but in the long term we probably want options to set the 
individually.

Create random payload.

This makes the data more like real traffic.  In particular repetitive patterns 
might be compressed by 
some devices thus skewing results.

Explaination of new feature

If --uuid is specified, every time a client connects to a server, client and 
server send a UUID to each other:

* If --uuid-string is specified and valid, this string is used
* If /etc/hostuuid exists and the content is valid (a single UUID with newlines 
and whitespaces after the UUID ignored), this string is used
* If none of the above applies, a UUID version 1 or 4 is generated. Default is 
version 1. Can be overridden by --uuid-version

Version 1 is not cryptographically secure, but it would help a _lot_ in 
determining which connection came from where; see [1].


Both client and server display their own and the partner's UUID and save it to 
the log file in [2].


For every transmission, a UUID is generated by the client and sent to the 
server. Both client and server display this UUID.


Justification of new feature

Cross-referencing of log files. Long-term storage of results, etc.



Richard

PS: I can supply a perl script to handle /etc/hostuuid and I still hope to get 
this into Debian proper. We use it internally and it saves a _lot_ of work to 
have hostuuids.

[1] http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Definition
[2] http://code.google.com/p/iperf/issues/detail?id=24

Aaron Brown <[email protected]> suggested:

Currently the code defaults to the AF_INET domain (IPv4). The default should be 
AF_UNSPEC.

Things to change:
1.) Set the default to AF_UNSPEC
2.) Change support code to reflect this change
3.) Add an IPv4 flag (-4) for specifying an IPv4 iperf test

Explaination of new feature

use netlogger like messages to report the results from server to client.

Justification of new feature

makes things easier to parse locally without messing with fixed length packet 
formats

What steps will reproduce the problem?
1. On Server A  /opt/iperf3 --client 10.10.205.13 --port 55525   --udp --debug
2. On Server B /opt/iperf3 --format k --port 55525 --udp --server -V
3.

What is the expected output? What do you see instead?
ON A:
Connecting to host 10.10.205.13, port 55525

ON B:
Accepted connection from 10.10.24.14, port 37180
      Cookie: e47a1dcd-70b4-44b5-9411-e59ade43f579

What version of the product are you using? On what operating system?
[root@horoscope opt]# /opt/iperf3 -v
iperf version 3.0-BETA4 (2 Aug 2010) 


Please provide any additional information below.
When I remove --udp it works just fine.

Explaination of new feature

when a signal is received in a send or recv it will cause a partial 
send/recieve. 
add an element to iperf_stream to allow a signal handler to decide how streams 
should handle the 
interrupted call -- continue reading or exit.

Justification of new feature

Explaination of new feature

Add windows support

Justification of new feature

Should be done, but I don't want to do it.

-d evaluates if -c is set before all option parsing is done.

This means that

    iperf -dc host

will not start a dual test while

    iperf -c host -d

does; obviously this behavior is undesirable.



host1:~% iperf -dc host2
WARNING: option -d is not valid for server mode
------------------------------------------------------------
Client connecting to host2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local host1 port 42220 connected with host2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec    376 MBytes    315 Mbits/sec
host1:~% iperf -c host2 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to host2, TCP port 5001
TCP window size: 63.1 KByte (default)
------------------------------------------------------------
[  5] local host1 port 42221 connected with host2 port 5001
[  4] local host1 port 5001 connected with host2 port 57550
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec  98.7 MBytes  82.8 Mbits/sec
[  4]  0.0-10.0 sec    978 MBytes    817 Mbits/sec
host1:~% 

Explaination of new feature

allow a library user to pass in a fd rather than having the stream functions 
allocate it.

The 'burst mode' in the new version of nuttcp sounds useful.

Here is the description from Chris Tracy:


"nuttcp has a new option that allows you
to specify that traffic is sent in bursts, instead of a nice smooth
transfer.  This is extremely useful in determining if a switch has
enough buffering to handle a 10GigE -> GigE translation (e.g. in
general, most cheaper 1U switches cannot handle this, while bigger
modular switches do have the buffering to handle it).  I recently ran
into this issue when sending from a host with a 10GigE NIC using a
bursty application (UltraGrid) and I ended up with 250Mbps (averaged
but extremely bursty) going into a 10GigE port on a 1U switch and only
80Mbps coming out of the GigE port.  iperf/nuttcp in standard rate
limit mode set to 250Mbps did not trigger the problem, but nuttcp's
new burst testing mode will reproduce the buffering issue."

See the code at: 
ftp://ftp.lcp.nrl.navy.mil/u/bill/private/nuttcp-6.3.1-beta2.c to see how
this is implemented.

Explaination of new feature:
Is there any way to implement a feature where iperf loops a 
pattern given in a file rather than just sending the file content once, as in 
Iperf2 with the "-F" option.

Justification of new feature
I'm working with systems that are able to compress packets and I believe this 
could be a useful feature of Iperf.

What steps will reproduce the problem?
1. iperf -s -T
2. iperf -c <host>
3.

What is the expected output? What do you see instead?

Expected TCPINFO results got a segfault

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. Install RHEL6.0 x86_64 bit OS. Gunzip,untar iperf files
2. Do ./configure, you get library files not found or ./congure throws "newly 
created files is older than distrubited files" Check your system clock
3. Unable to proceed further.

What is the expected output? What do you see instead?
Installation should go through fine as with previous version of iperf2xx

What version of the product are you using? On what operating system?
Iperf-3.0b4.tar

Please provide any additional information below.
Package should come with all the required lib files and should synchronise 
properly.

What steps will reproduce the problem?
1.iperf -s -u -f k -w 122.0K -l 1.0K
2.iperf -u -c x.x.x.x -f k -w 122.0K -l 1.0K -b 50.0K -t 30
3.

What is the expected output? What do you see instead?
a correctly UDP test. the transmissionis interrupted during 8-10 sec 

What version of the product are you using? On what operating system?
iperf 2.0.4. Debian GNU/Linux 5.0

Please provide any additional information below.
i have tested with differents values of -w, -l, -b...but the transmission is 
always interrupted...

A link on the following pages back to this project would be useful:

http://iperf.sourceforge.net/

http://sourceforge.net/projects/iperf/

Explaination of new feature
Provide API to remotely control the sender to change traffic pattern. This will 
allow a user to run at 10mbps UDP for some time and then change to 60mbps on 
the same udp port. 

Justification of new feature
This allows for showing affect of varying traffic on a system.

Explaination of new feature

It would be helpful to be able to send a known number of packets at a known 
rate, so that the 
packets can be counted at the far end.  The idea is to be able to measure the 
ability of the 
network to handle bursty behavior without requiring that the network devices be 
able to count 
packets reliably (Juniper routers can, most others cannot).

This is similar to the burst mode enhancement request.

It might be desirable to  have a flag to prime the flow cache of the routers 
along the path (routers 
with a punt-first architecture typically rely on the TCP handshake to get the 
hardware forwarding 
primed, so a big burst out of the blue might experience loss that a 
non-synthetic TCP stream 
might not experience).  The counting mechanism would have to take these 
"priming packets" into 
consideration.

Explaination of new feature

add things like the version number of iperf and possibly uname(1) type info.

Justification of new feature

Many/most Iperf bug reports include Iperf output but frequently omit the 
version number and/or OS.

What steps will reproduce the problem?
1. it's in the code

this is very confusing and potentially evil behavior for a library, needs to be 
handled at the tool 
level.

Explaination of new feature

Support for Multicast testing.

Justification of new feature

A lot of video is multicast and has QOS implication that would desire testing. 

Explaination of new feature

-L or --log-file will save all data to a log file.
iperf will quit with an error if the target file exists unless -A or --append 
is specified.
Both a client & server option.

Justification of new feature

I need to keep logs, sometimes.

With gethostbyname(3), you should use herror(3) for error reporting.

Please find an attached patch file.

What steps will reproduce the problem?
1. Raspberry PI & Debian wheezy installed on it.
2. Download iperf3 and compile it.
3. Fix: 
https://groups.google.com/forum/?fromgroups=#!topic/iperf-dev/MzL9zMzZ1Co
4. Run "./iperf3 -s" on one tty and "./iperf3 -c localhost -t 2" on the other.

What is the expected output? What do you see instead?
System call accept does not accept connection and stays blocked:

root@rpitc:~/iperf-3.0b4# ./src/iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Staring iperf_accept
Before accept call.
^CAfter accept call.

What version of the product are you using? On what operating system?
Raspberry PI:
root@rpitc:~# uname -a
Linux rpitc 3.2.27-rpitc+ #3 PREEMPT Thu Aug 30 10:19:18 CEST 2012 armv6l 
GNU/Linux

root@rpitc:~# cat /etc/issue.net 
Debian GNU/Linux wheezy/sid

Please provide any additional information below.
Tcpdump output in raspberry_pi txt file.

Explaination of new feature

use the primitives in queue.h rather than homegrown

Justification of new feature

more standard, clearer, less bug prone

the TCP_INFO getsockopt provides information about the current state of a TCP 
session. This 
information can give significant insight into TCP performance issues.

Now, I have a Macintosh with OS X 10.5. I downloaded the source file 
iperf-3.0b4.tar.gz . I attempted to compile it with the GCC 4.0.1. The compile 
process failed. 

What steps will reproduce the problem?
1. Extract iperf-3.0b4.tar.gz to a directory on Mac OS X Darwin.
2. As the README says, do ./configure and make.
3. Output from the configure and make is posted below for your information.

What is the expected output? What do you see instead?
I expected that the source was compiled into a binary executable. But I 
couldn't see any binary executable. Some error message from the compiling 
process appeared. It is posted below.

What version of the product are you using? On what operating system?
I downloaded the iperf-3.0b4.tar.gz file. I compiled it on Mac OS X 10.5 using 
GCC 4.0.1.

Please provide any additional information below.
Output from ./configure:
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... config/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking build system type... i386-apple-darwin9.8.0
checking host system type... i386-apple-darwin9.8.0
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld
checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU 
ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p
checking the name lister (/usr/bin/nm -p) interface... BSD nm
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload 
object files... -r
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... (cached) ranlib
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) 
supports shared libraries... yes
checking dynamic linker characteristics... darwin9.8.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ANSI C header files... (cached) yes
checking for uuid_create... no
checking for uuid_generate... yes
checking uuid.h usability... no
checking uuid.h presence... no
checking for uuid.h... no
checking uuid/uuid.h usability... yes
checking uuid/uuid.h presence... yes
checking for uuid/uuid.h... yes
checking for an ANSI C-conforming const... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing libtool commands

Output from make:
Making all in src
make  all-am
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT iperf_api.o -MD -MP -MF 
.deps/iperf_api.Tpo -c -o iperf_api.o iperf_api.c
mv -f .deps/iperf_api.Tpo .deps/iperf_api.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT iperf_error.o -MD -MP -MF 
.deps/iperf_error.Tpo -c -o iperf_error.o iperf_error.c
mv -f .deps/iperf_error.Tpo .deps/iperf_error.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT iperf_client_api.o -MD -MP -MF 
.deps/iperf_client_api.Tpo -c -o iperf_client_api.o iperf_client_api.c
mv -f .deps/iperf_client_api.Tpo .deps/iperf_client_api.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT iperf_server_api.o -MD -MP -MF 
.deps/iperf_server_api.Tpo -c -o iperf_server_api.o iperf_server_api.c
mv -f .deps/iperf_server_api.Tpo .deps/iperf_server_api.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT iperf_tcp.o -MD -MP -MF 
.deps/iperf_tcp.Tpo -c -o iperf_tcp.o iperf_tcp.c
mv -f .deps/iperf_tcp.Tpo .deps/iperf_tcp.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT iperf_udp.o -MD -MP -MF 
.deps/iperf_udp.Tpo -c -o iperf_udp.o iperf_udp.c
mv -f .deps/iperf_udp.Tpo .deps/iperf_udp.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT iperf_util.o -MD -MP -MF 
.deps/iperf_util.Tpo -c -o iperf_util.o iperf_util.c
mv -f .deps/iperf_util.Tpo .deps/iperf_util.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT locale.o -MD -MP -MF .deps/locale.Tpo -c 
-o locale.o locale.c
mv -f .deps/locale.Tpo .deps/locale.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT net.o -MD -MP -MF .deps/net.Tpo -c -o 
net.o net.c
mv -f .deps/net.Tpo .deps/net.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT tcp_info.o -MD -MP -MF 
.deps/tcp_info.Tpo -c -o tcp_info.o tcp_info.c
mv -f .deps/tcp_info.Tpo .deps/tcp_info.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT tcp_window_size.o -MD -MP -MF 
.deps/tcp_window_size.Tpo -c -o tcp_window_size.o tcp_window_size.c
mv -f .deps/tcp_window_size.Tpo .deps/tcp_window_size.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT timer.o -MD -MP -MF .deps/timer.Tpo -c 
-o timer.o timer.c
mv -f .deps/timer.Tpo .deps/timer.Po
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT units.o -MD -MP -MF .deps/units.Tpo -c 
-o units.o units.c
mv -f .deps/units.Tpo .deps/units.Po
rm -f libiperf.a
ar cru libiperf.a iperf_api.o iperf_error.o iperf_client_api.o 
iperf_server_api.o iperf_tcp.o iperf_udp.o iperf_util.o locale.o net.o 
tcp_info.o tcp_window_size.o timer.o units.o 
ranlib libiperf.a
gcc -DHAVE_CONFIG_H -I.    -g -Wall -g -O2 -MT iperf3-main.o -MD -MP -MF 
.deps/iperf3-main.Tpo -c -o iperf3-main.o `test -f 'main.c' || echo './'`main.c
mv -f .deps/iperf3-main.Tpo .deps/iperf3-main.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc -g -Wall -g -O2   -o iperf3 
iperf3-main.o libiperf.a 
libtool: link: gcc -g -Wall -g -O2 -o iperf3 iperf3-main.o  libiperf.a
gcc -DHAVE_CONFIG_H -I.    -g -Wall -g -O2 -MT t_timer-t_timer.o -MD -MP -MF 
.deps/t_timer-t_timer.Tpo -c -o t_timer-t_timer.o `test -f 't_timer.c' || echo 
'./'`t_timer.c
t_timer.c: In function 'main':
t_timer.c:13: warning: implicit declaration of function 'sleep'
mv -f .deps/t_timer-t_timer.Tpo .deps/t_timer-t_timer.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc -g -Wall -g -O2 iperf_error.o  -o 
t_timer t_timer-t_timer.o libiperf.a 
libtool: link: gcc -g -Wall -g -O2 iperf_error.o -o t_timer t_timer-t_timer.o  
libiperf.a
gcc -DHAVE_CONFIG_H -I.    -g -Wall -g -O2 -MT t_units-t_units.o -MD -MP -MF 
.deps/t_units-t_units.Tpo -c -o t_units-t_units.o `test -f 't_units.c' || echo 
'./'`t_units.c
mv -f .deps/t_units-t_units.Tpo .deps/t_units-t_units.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc -g -Wall -g -O2   -o t_units 
t_units-t_units.o libiperf.a 
libtool: link: gcc -g -Wall -g -O2 -o t_units t_units-t_units.o  libiperf.a
gcc -DHAVE_CONFIG_H -I.    -g -Wall -g -O2 -MT t_uuid-t_uuid.o -MD -MP -MF 
.deps/t_uuid-t_uuid.Tpo -c -o t_uuid-t_uuid.o `test -f 't_uuid.c' || echo 
'./'`t_uuid.c
mv -f .deps/t_uuid-t_uuid.Tpo .deps/t_uuid-t_uuid.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc -g -Wall -g -O2   -o t_uuid 
t_uuid-t_uuid.o libiperf.a 
libtool: link: gcc -g -Wall -g -O2 -o t_uuid t_uuid-t_uuid.o  libiperf.a
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-main.o -MD -MP 
-MF .deps/iperf3_profile-main.Tpo -c -o iperf3_profile-main.o `test -f 'main.c' 
|| echo './'`main.c
mv -f .deps/iperf3_profile-main.Tpo .deps/iperf3_profile-main.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-iperf_api.o -MD 
-MP -MF .deps/iperf3_profile-iperf_api.Tpo -c -o iperf3_profile-iperf_api.o 
`test -f 'iperf_api.c' || echo './'`iperf_api.c
iperf_api.c: In function 'iperf_reporter_callback':
iperf_api.c:1128: warning: 'avg_jitter' may be used uninitialized in this 
function
mv -f .deps/iperf3_profile-iperf_api.Tpo .deps/iperf3_profile-iperf_api.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-iperf_error.o 
-MD -MP -MF .deps/iperf3_profile-iperf_error.Tpo -c -o 
iperf3_profile-iperf_error.o `test -f 'iperf_error.c' || echo './'`iperf_error.c
mv -f .deps/iperf3_profile-iperf_error.Tpo .deps/iperf3_profile-iperf_error.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT 
iperf3_profile-iperf_client_api.o -MD -MP -MF 
.deps/iperf3_profile-iperf_client_api.Tpo -c -o 
iperf3_profile-iperf_client_api.o `test -f 'iperf_client_api.c' || echo 
'./'`iperf_client_api.c
mv -f .deps/iperf3_profile-iperf_client_api.Tpo 
.deps/iperf3_profile-iperf_client_api.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT 
iperf3_profile-iperf_server_api.o -MD -MP -MF 
.deps/iperf3_profile-iperf_server_api.Tpo -c -o 
iperf3_profile-iperf_server_api.o `test -f 'iperf_server_api.c' || echo 
'./'`iperf_server_api.c
iperf_server_api.c: In function 'iperf_server_listen':
iperf_server_api.c:52: warning: unused variable 'x'
iperf_server_api.c:51: warning: unused variable 'ubuf'
mv -f .deps/iperf3_profile-iperf_server_api.Tpo 
.deps/iperf3_profile-iperf_server_api.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-iperf_tcp.o -MD 
-MP -MF .deps/iperf3_profile-iperf_tcp.Tpo -c -o iperf3_profile-iperf_tcp.o 
`test -f 'iperf_tcp.c' || echo './'`iperf_tcp.c
mv -f .deps/iperf3_profile-iperf_tcp.Tpo .deps/iperf3_profile-iperf_tcp.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-iperf_udp.o -MD 
-MP -MF .deps/iperf3_profile-iperf_udp.Tpo -c -o iperf3_profile-iperf_udp.o 
`test -f 'iperf_udp.c' || echo './'`iperf_udp.c
mv -f .deps/iperf3_profile-iperf_udp.Tpo .deps/iperf3_profile-iperf_udp.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-iperf_util.o -MD 
-MP -MF .deps/iperf3_profile-iperf_util.Tpo -c -o iperf3_profile-iperf_util.o 
`test -f 'iperf_util.c' || echo './'`iperf_util.c
mv -f .deps/iperf3_profile-iperf_util.Tpo .deps/iperf3_profile-iperf_util.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-locale.o -MD -MP 
-MF .deps/iperf3_profile-locale.Tpo -c -o iperf3_profile-locale.o `test -f 
'locale.c' || echo './'`locale.c
mv -f .deps/iperf3_profile-locale.Tpo .deps/iperf3_profile-locale.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-net.o -MD -MP 
-MF .deps/iperf3_profile-net.Tpo -c -o iperf3_profile-net.o `test -f 'net.c' || 
echo './'`net.c
mv -f .deps/iperf3_profile-net.Tpo .deps/iperf3_profile-net.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-tcp_info.o -MD 
-MP -MF .deps/iperf3_profile-tcp_info.Tpo -c -o iperf3_profile-tcp_info.o `test 
-f 'tcp_info.c' || echo './'`tcp_info.c
mv -f .deps/iperf3_profile-tcp_info.Tpo .deps/iperf3_profile-tcp_info.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT 
iperf3_profile-tcp_window_size.o -MD -MP -MF 
.deps/iperf3_profile-tcp_window_size.Tpo -c -o iperf3_profile-tcp_window_size.o 
`test -f 'tcp_window_size.c' || echo './'`tcp_window_size.c
mv -f .deps/iperf3_profile-tcp_window_size.Tpo 
.deps/iperf3_profile-tcp_window_size.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-timer.o -MD -MP 
-MF .deps/iperf3_profile-timer.Tpo -c -o iperf3_profile-timer.o `test -f 
'timer.c' || echo './'`timer.c
mv -f .deps/iperf3_profile-timer.Tpo .deps/iperf3_profile-timer.Po
gcc -DHAVE_CONFIG_H -I.    -pg -Wall -g -O2 -MT iperf3_profile-units.o -MD -MP 
-MF .deps/iperf3_profile-units.Tpo -c -o iperf3_profile-units.o `test -f 
'units.c' || echo './'`units.c
mv -f .deps/iperf3_profile-units.Tpo .deps/iperf3_profile-units.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc -pg -Wall -g -O2   -o 
iperf3_profile iperf3_profile-main.o iperf3_profile-iperf_api.o 
iperf3_profile-iperf_error.o iperf3_profile-iperf_client_api.o 
iperf3_profile-iperf_server_api.o iperf3_profile-iperf_tcp.o 
iperf3_profile-iperf_udp.o iperf3_profile-iperf_util.o iperf3_profile-locale.o 
iperf3_profile-net.o iperf3_profile-tcp_info.o iperf3_profile-tcp_window_size.o 
iperf3_profile-timer.o iperf3_profile-units.o libiperf.a 
libtool: link: gcc -pg -Wall -g -O2 -o iperf3_profile iperf3_profile-main.o 
iperf3_profile-iperf_api.o iperf3_profile-iperf_error.o 
iperf3_profile-iperf_client_api.o iperf3_profile-iperf_server_api.o 
iperf3_profile-iperf_tcp.o iperf3_profile-iperf_udp.o 
iperf3_profile-iperf_util.o iperf3_profile-locale.o iperf3_profile-net.o 
iperf3_profile-tcp_info.o iperf3_profile-tcp_window_size.o 
iperf3_profile-timer.o iperf3_profile-units.o  libiperf.a
make[1]: Nothing to be done for `all-am'.

What steps will reproduce the problem?
1. iperf -S [this will not work on windows XP]
2.
3.

What is the expected output? What do you see instead?
Should send prioritized output but i didn't see this on my sniffer trace. 

What version of the product are you using? On what operating system?
2.0.5 compiled using cygwin. windows XP OS

Please provide any additional information below.

make[2]: Entering directory `/home/build/inovick/iperf-3.0b4/src'
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT iperf_api.o -MD -MP -MF 
.deps/iperf_api.Tpo -c -o iperf_api.o iperf_api.c
iperf_api.c:17:23: error: sys/queue.h: No such file or directory
In file included from iperf_api.c:32:

When I try to build on FreeBSD (www-eng9.es.net), I get this error:

(doing ./configure; make)

/usr/bin/ld: cannot find -lgcc_eh_p

It can often be helpful to know the average CPU utilization for both the 
sending and receiving hosts during an iperf, to determine if one side is 
CPU-bound.

As an example, nuttcp reports CPU utilization on the summary line at the end of 
a transfer, e.g. "%TX" and "%RX" in the output below:

70908.4355 MB /  60.06 sec = 9903.3007 Mbps 19 %TX 43 %RX 0 retrans 0.10 
msRTT

(Of course, when you run nuttcp in UDP mode, it is expected that the TX side 
will go to 100%...)

For testing in firewalled environments, it would be useful to be able to run 
iperf over a single port (including port 80)

I am trying to make this compile in Solaris 1o for SPARC using the Sun Studio 
compiler ver. 12  and i get the following error for 'errno'

------------------------< cut here> ------------------------------
$ gmake
cc -g    -c -o main.o main.c
"main.c", line 272: warning: statement not reached
cc -g    -c -o iperf_api.o iperf_api.c
"iperf_api.c", line 805: warning: statement not reached
cc -g    -c -o iperf_server_api.o iperf_server_api.c
"iperf_server_api.c", line 179: warning: improper pointer/integer combination: o
"iperf_server_api.c", line 195: warning: improper pointer/integer combination: o
cc -g    -c -o iperf_tcp.o iperf_tcp.c
cc -g    -c -o iperf_udp.o iperf_udp.c
cc -g    -c -o timer.o timer.c
"timer.c", line 120: undefined symbol: errno
cc: acomp failed for timer.c
gmake: *** [timer.o] Error 1


$ CC -V
CC: Sun C++ 5.10 SunOS_sparc 128228-08 2010/04/21
Usage: CC [ options ] files.  Use 'CC -flags' for details
---------------------------< cut here >-----------------------------

Explaination of new feature
want to use iperf3.0 in win7 OS.

Justification of new feature
use two clients, one is WIN7 os, one is linux(ubuntu)
connect to the same home router and do performance test.

Explaination of new feature
An option to set the Flow Label field in the IPv6 header for an outgoing stream 
on the client side.

Justification of new feature
To permit the testing of IPv6 QoS implementations based on the Flow Label field.

Explaination of new feature

stop a running test.

Justification of new feature

it's useful!