Tag Info

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

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

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

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 ...


3

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 ...


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

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

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 ...


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

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 ...


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

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 ...


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

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)


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

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 ...


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


1

Check if your switch (your network cards should already support it) is accidentally not set to auto-mdix or if there is fixed value and you got a mismatch. This can cause the problems you describe, I've seen the exact same behaviour in our own network with a mismatch. Sometimes auto-mdix might not work and you should also try setting it to the same value on ...


1

Gravyface, I have had similar experiences as you have described... all under Windows XP... my solution to this issue was to burn a couple of Knoppix discs. My results instantly made sense, which leads me to believe it was an issue due to "something from Redmond"... but I couldn't say what it was.


1

Iperf will generate up to a Gigabit or so, depending on hardware. If you want to max out 10 Gbit connections (or above), or use smaller than MTU packets you will have to use kernel modules such as pktgen.


1

Have you tried just using Jperf (Java-based)? It's at version 2.0.x and seems to have the same functionality as iperf: http://sourceforge.net/projects/iperf/


1

I've recently compiled iperf on windows using cygwin here's the output of iperf -v [iperf version 2.0.5 (08 Jul 2010) pthreads]


1

iperf - measure network performance Pretty much the standard tool, imo windows exe: http://www.noc.ucf.edu/Tools/Iperf/



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