Tag Info

Hot answers tagged

6

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


6

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


5

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


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


4

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


3

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


3

I'd 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 hosts indicates this with a corresponding ICMP message to the source. In order to run iperf you must have a server running on ...


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


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

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?


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

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

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

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

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

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

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


1

Yes, this is reasonably safe. People do this all the time, and they tend to be people who are sensitive to network security issues. iperf3 is a rewrite of the original iperf software and has received more scrutiny then the original package, and iperf3 was created at a time when network security really does matter. The iperf3 developers do fix bugs and I ...


1

Have you made sure there is no sensitive data on that server? Are you 100% certain it has absolutely zero access to the rest of your servers? If yes to both, then it's ok.


1

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.


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

I figured this by typing ulimit -a which shows all the kernel limits . ulimit -n returns unlimited while ulimit -a returns the value for nofile as 1024. I set the limits in the /etc/security/limits.conf file in the format ** soft nofile 8192 hard nofile 65000 and things worked


1

UDP doesn't have transmit pacing, congestion backoff, and the other features TCP has. If you don't implement them, throughput will suffer terribly -- that's why TCP implements them. Iperf doesn't have the necessary logic to find the maximum UDP transfer rate. You would need to increase the rate so long as all packets were getting through and back off when ...


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.



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