RE: Problems with iperf 1.6.3, that don't happen with 1.2
On Tue, 26 Nov 2002, Yaniv Kaul wrote:
> 1. I'm not sure what sockets it is destroing before cancelling a call - It
> was merely listening, without getting any connections yet!
Ok more accurately ONE socket. The socket that we are listening on. Which
with UDP is actually a recvfrom since there is no listen accept mechanism.
In case you missed it, in the KNOWN_PROBLEMS file it lists this as the
first problem.
> 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).
Well I just ran through the entire diff between 1.2.1 and 1.6.3 (the
oldest and latest available in our cvs tree). I find nothing that would
contribute to this situation you speak of. Breakdown; 12267 lines of /cfg
and Makefile changes to support more OSes, 176 lines in the /doc, 3106
lines (44/file for copyright notice) in /lib to support IPv6 structures
and changed the iperf define thread_t to nthread_t, 2903 lines (44/file
for copyright notice and 2 whole files due to change in endline
characters) of changes for IPv6 and Win32 Service handling.
As you can see there are really no changes that would affect the "nice"
working of Iperf. Are you sure you are running a multithreaded Iperf 1.2?
Check with `iperf -v`. A single threaded version would be more stable as
scheduling would be more deterministic than with pthreads handling.
Otherwise I have no idea why you are getting the different operating
results.
Kevin
> -----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/