Re: Windows problems and Linux question

[Kevin G. <kg...@nc...>]

First Win32 is a horrible handler of UDP traffic. For a Win32 UDP server 
you do not want to send more than one simultaneous stream at it at any 
given time. If your 2 clients were overlapping in their streams than a lot 
of bad things could potentially happen. As for the second problem of 
continual stream of "read failed..." I will have to investigate that some 
more. It is a UDP FIN ACK (Iperf mimics TCP shutdown mechanisms so that it 
can cleanup server resources) issue.

Kevin

On Wed, 17 Dec 2003, Gregg Hamby wrote:

>   Greetings all. I merely wanted to offer my experiences re: iperf 1.7 
>   on Windows. I saw another post in which someone stated that their 
>   windows systems were stopping and that they could not run iperf as a 
>   service on Windows. I too had the same problems. In my case, iperf was 
>   running on three different (identical) laptops - Compaq Armada e500s 
>   running Windows XP SP1A using the built in Ethernet adapter.
>   In each case iperf would run but would hang after a day or so of 
>   continual use.
>   I was performing UDP tests from two clients to one server and used 
>   the Windows task scheduler to run the clients at 5 minute intervals.
>   Typically I would come back to the client and discover it had 'hung' 
>   and had to be killed and restarted.
>   After attempting to get that to work I simply deployed Red Hat 8 on 
>   each laptop and began using that. It is working much better and I was 
>   able to collect UDP data for 13 days straight.
>   However, I do see one error appear on the server machine. After 
>   several hours the server will report "read failed:connection refused" 
>   (continuous scroll) but iperf is still running and logging data?
>   On the server, I am simply running ./iperf -u -s >> <name of my log file>
> 
>   On each client I am running ./iperf -c <ip of host> -u >> <log file> 
>   at 10 minute intervals via cron.
>   Any idea what the server error is and what it might mean? Since 
>   iperf continues to function I didn't consider it critical.
> 
>   Thanks,
>   Gregg.
>