FYI, The iperf 2.0.14 now supports a --ful-duplex option. This is different than --bidir as it uses a single socket and treats it as full duplex. I'm noticing full duplex performance issues on some early redhat releases. I'm assuming it's not been tested much before.
Man page notes: *Reverse, full-duplex, dualtest (-d) and tradeoff (-r):* The --reverse (-R) and --full-duplex options can be confusing when compared to the older options of --dualtest (-d) and --tradeoff (-r). The newer options of --reverse and --full-duplex only open one socket and read and write to the same socket descriptor, i.e. use the socket in full duplex mode. The older -d and -r open second sockets in the opposite direction and do not use a socket in full duplex mode. *Note that full duplex applies to the socket and not to the network devices* and that full duplex sockets are supported by the operating systems regardless if an underlying network supports full duplex transmission and reception. It's suggested to use --reverse if you want to test through a NAT firewall (or -R on non-windows systems). This applies role reversal of the test after opening the full duplex socket. (Note: Firewall piercing may be required to use -d and -r if a NAT gateway is in the path.) Also, the --reverse -b <rate> setting behaves differently for TCP and UDP. For TCP it will rate limit the read side, i.e. the iperf client (role reversed to act as a server) reading from the full duplex socket. This will in turn flow control the reverse traffic per standard TCP congestion control. The --reverse -b <rate> will be applied on transmit (i.e. the server role reversed to act as a client) for UDP since there is no flow control with UDP. There is no option to directly rate limit the writes with TCP testing when using --reverse. Thanks, Bob
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Iperf-users mailing list Iperf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iperf-users
