Hot answers tagged

8

As it is said above, iperf limits itself by design. In src/Client.cpp, method void Client::Run( void ) calls ReportPacket( mSettings->reporthdr, reportstruct ); after writing each UDP datagram. ReportPacket() is rather slow and it slows the whole thing. In iperf3, burst writes are introduced for UDP, you can specify number of burst writes in -b ...


7

The problem is inside iperf itself. When you send a UDP flow iperf will do some internal bookkeeping for each datagram in the flow. On the other hand when you send a TCP stream iperf does bookkeeping only once per stream. In my measurements it came out that iperf-UDP wastes a lot of time doing the per-datagram measurements hence the slower performance. If ...


6

@Chris - No it won't. And on that note, you can download the native compiled binary v2.0.4 from here. (warning: shameless plug, if it even is that - links to my site).


5

I doubt that this is a firewall issue. Usually, firewalls employ the DROP rule for packets that are not allowed. A "connection refused" means that there is no application listening on the port it tries to connect to. The destination host indicates this with a corresponding ICMP message to the source. In order to run iperf you must have a server running on ...


5

Each frame goes through several buffers as you send it: The application buffer, The Protocol Buffer, The Software interface buffer and the Hardware interface buffer. As you start stressing the stack by sending high speed data you will fill up these buffers and either block or lose data. You also have strategies for timeliness and polling that can impact your ...


4

The fields are timestamp,source_address,source_port,destination_address,destination_port,interval,transferred_bytes,bits_per_second I deduced this by looking at $ iperf -c localhost -r ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ...


4

To my knowledge, yes.. you need two hosts running iperf at each end: One server with the command: iperf -s One client with the command: iperf -c ser.ver.ip.address Here's a windows binary you can use: https://nocweboldcst.ucf.edu/files/iperf.exe (run it from the command line in windows) Here's a tutorial I've used for a while that pretty much has most ...


4

iperf is capable of bidrectional tests, either simultaneously with "-d" or sequentially with "-r". Using "-r" will test bandwidth from client to server first, then server to client afterwards which is what you're after, I believe.


4

There is no problem. This is normal and expected behaviour. The reason for the packet loss is that UDP doesn't have any congestion control. In tcp when congestion control algorithms kick in, it will tell the transmit end to slow down the sending in order to maximise throughput and minimise loss. So this is entirely normal behaviour for UDP actually. UDP ...


3

It doesn't. iperf doesn't care though, it just blasts the data out anyway. Apache will react with a "414 Request URI too large" error page, which will be answered with even more useless data by iperf. iperf doesn't need an iperf server on the other end, just a willing "victim" that doesn't cut the connection.


3

Your network card uses the Intel igb driver. Under VMware and Linux, that device/driver can be troublesome. I'd try the following: Your ESXi build number is 1331820 and includes version 4.2.16.8 of the igb NIC driver. The current ESXi build has version 5.0.5.1.1 of the igb driver. An update of ESXi may be appropriate. The defaults on the igb driver don't ...


3

I've experienced significant dataloss with iPerf in UDP mode as a result of the CPU not being able to keep up. For some reason, iPerf with UDP seems to be much more CPU intensive than iPerf with TCP. Do you experience the same loss percentages when you set iPerf to half the rate? To answer your second question about how much packet loss is acceptable, it ...


3

Packgen says it supports the DSCP that you reqaire: http://packgen.rubyforge.org/files/README.html Scapy is another: http://www.secdev.org/projects/scapy here is a nice list of generators/tools: http://www.protocoltesting.com/trgen.html


3

Probably it's worth a read of this "Why TCP over TCP is a bad idea", it would be better to use a VPN than to rely on SSH for anything more than throw away tunnels. Admittedly, that's a lot slower than I would have expected, even from an SSH tunnel. Perhaps you need to tune your SSH options.


3

I just had the same question and found a patch that seemed to work (after some extra futzing). You can checkout the patched iperf code here: https://github.com/tierney/iperf If you're using Linux, building should be as easy as ./configure && make; the executable will be at src/iperf. Just add the --reverse flag to both the client and server ...


3

It could be: Something is blocking the traffic between your hosts. You specified UDP on the client command, did you do the same on the server side? The client connection to the server should generate output indicating it has connected, are you seeing this?


3

Is it possible to gather the same results by sending regular data, as in not testing data? I don't believe so, at least not using iperf. If you can capture the real data with pcap/tcpdump/wireshark, then you should be able to use wireshark to determine the jitter. I suspect iperf calculates jitter using a formula like is defined in RFC 3550 for the ...


2

We use quite a bit of DLink here, sadly. Have you verified that every single on of those links between the switches is actually operating at the speed that you want them to? No sense poking about with performance testing software if you don't know that those links are running at full rated speed. There's lights on the front of those switches above each ...


2

There is a lot of 5E cable around that is sub-par. Even if it says 5E on the box or on the cable itself that doesn't mean it can actually do it. It is quite common for such cable to fall back to 100 Mb/s or even less. Getting Gigabit over more than 30 feet is usually quite a feat in those cases. That would explain the 97 Mb/s between (1) and (4). As ...


2

Yes, this traffic is transferred locally without reaching your physical interfaces. It is transferred using the loopback interface. The kernel detects that the destination is a local one, so the traffic is looped back to the machine itself without going through eth0 or eth1.


2

The later version of iperf you have is using a different threading library (win32 threads vs. pthread). That alone could explain the difference in performance. There could be some other code difference between 1.x and 2.x of iperf. It could be simple like the default options changed from 1.x to 2.x (such as TCP_WINDOW_SIZE, ...). Make sure both are using ...


2

Yes, iPerf can easily max out even Gb connections. The example above by mkudlacek is, in fact, a maxed out connection, minus losses to TCP overhead. ------------------------------------------------------------ Client connecting to proton.cw, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ ...


2

Traffic way is from client to server. From manpage: To perform an iperf test the user must establish both a server (to discard traffic) and a client (to generate traffic)


2

I think you're asking the same question as at: iperf-like bidirectional bandwidth measurement through NAT I responded there, but the tl;dr is that I found a patch for iperf that enables NAT'd clients to initiate reverse TCP iperf tests. The full, patched iperf code is here: https://github.com/tierney/iperf


2

Yes, I just implemented a check for this myself and I can confirm that the first 4 bytes of the data is in fact the sequence number.


2

It's in EPEL, so you have to to enable that repo first; yum install epel-release


2

HTB bandwidth control in tc only shapes outgoing traffic, so in order to limit the bandwidth between a server and client TCP connect, shaping must be applied to both bridge interfaces. (Thanks to 0x534B41)


1

In case anyone has this issue (or similar), the problem in the end was the raspberry pi itself. Hardware fault for sure. I swapped the pi for a new one, exactly the same model, placed the same sd card in, with all the same cables, and everything has been working perfectly since...


1

What version of tcpreplay? Newer versions are faster then older versions. You really want to run the latest 4.x which supports injection via NETMAP. Also, are you sure you're on a 1Gbps or better interface? Are you connected to a 100Mbps switch port or for some reason negotiated 100Mbps? Look in /var/log/messages or dmesg to see how your interface ...


1

it might be an issue with the flow control on both the nic and switch, please see the following article and make sure you disable flow control on both the nic and switch. http://www.smallnetbuilder.com/content/view/30212/54/



Only top voted, non community-wiki answers of a minimum length are eligible