RE: IPERF 1.7.0 and UDP packet loss on Win32
In case anyone else experiences the same problem, the "solution" to the packet loss is to increase the UDP window size. With the default size of 8KB, this is only 5 packets (if they are full size Ethernet packets at ~1600 bytes each). Hence, if you don't respond to the incoming packets quickly, then you will lose them because the buffer fills up too fast. If you increase the buffer size to a much larger value (e.g. 256K or 1M) then this gives Windoze time to do its task switching or stdout operations but you will not lose the data.
I still don't know why the compilation issues are there, but since CYGWIN seems to work OK, I'm not too worried....
-----Original Message-----
From: Roger Lucas [mailto:roger.lucas --at-- st.com]
Sent: Wednesday, August 04, 2004 5:17 PM
To: 'iperf-users --at-- dast.nlanr.net'
Subject: IPERF 1.7.0 and UDP packet loss on Win32
All,
I have been having a lot of problems with IPERF and wireless LAN under Windows XP. I started by using the supplied Windoze executable on the IPERF site. This worked OK-ish, but could not generate packet streams above ~16 Mbits on the Netgear WLAN card (or any other WLAN card) - for some reason there were always regular gaps in the traffic (~5ms every ~20ms) which reduced the throughput. The PC is a 1 GHz PC and should not have any problems generating traffic at this rate.
Compiling with MSVC 6.0 was unsuccessful, and created an executable that would run but not send or receive packets. MSVC .NET was more successful, but although the executable would send packets OK, it would not detect any incoming packets. Compiling under CYGWIN was successful provided that you make sure the executable is compiled for single-threaded operation (which is not the default for CYGWIN if you follow the "make configure", "make" approach on Windoze). The CYGWIN executable sends and receives data at the underlying network rate (~30 Mbits). Unfortunately, the CYGWIN-generated is extremely sensitive to printf() calls, and will drop incoming packets whenever a printf() call is made. This means that if you run "iperf -sui 1" then you lost a burs tof ~20 packets every second, and you always lost a burst of packets at the start of the transfer when the server prints up the connection message.
Has anyone else experienced the above effects, and is there a straightforward solution ?
Thanks,
Roger Lucas