RE: Problems with iperf 1.6.3, that don't happen with 1.2
1. I'm not sure what sockets it is destroing before cancelling a call - It
was merely listening, without getting any connections yet!
2. 'works nicely' means that you do get 10Mb bandwidth of UDP traffic.
3. 'stable' means that connections are not bursty, but are consistently
giving X Mb throughput (so if you have a bandwidth monitoring software, you
get a more-or-less straight horizontal line).
-----Original Message-----
From: owner-iperf-users --at-- dast.nlanr.net
[mailto:owner-iperf-users --at-- dast.nlanr.net]On Behalf Of Kevin Gibbs
Sent: Tuesday, November 26, 2002 1:09 AM
To: iperf-users --at-- dast.nlanr.net
Subject: Re: Problems with iperf 1.6.3, that don't happen with 1.2
On Mon, 25 Nov 2002, Yaniv Kaul wrote:
> 1. On RH Linux 7.3, just compiled iperf 1.6.3, When pressing CTRL-C from a
> listening server ('./iperf -s -u -p 3333') produces a core. It does not
> happen on all machines (donno what the difference between them is...):
In my experience this has been due to destroying sockets before cancelling
the call into some socket function. Most of mine are preceded by recvfrom
failed: or select failed:. There is not much we can do about this, except
change the way we kill the server. The randomness is directly connected
to which threads get ran in which order, and how socket functions are
handled. I generally have not thought much of it, since I did want it to
stop!
> 2.Running ./iperf -c 10.6.62.2 -u -p 3333 -t 11111 -b 10Mb -P 5 gives
> bandwidth~ 173,000 - 208,000 Bps. On iperf 1.2 it works nicely.
Not sure what you are saying here. Define "wprks nicely".
> 3. Connections are less stable in bandwidth than in 1.2.
Define this more I have no idea what you mean, "less stable in
bandwidth"
Kevin
--
Mitch Kutzko | mitch --at-- dast.nlanr.net | mitch --at-- ncsa.uiuc.edu | 217-333-1199
http://hobbes.ncsa.uiuc.edu/