RE: multicast problems
I can vouch that two Iperf services can be running simultaneously, as I set an Iperf environment across our network previously with 2 different versions of the iperf service (key part being the service name, as kevin stated). I do have two compiled versions, but they are specific to our goals, in that one is running TCP on 5001 and the other is exclusively UDP on 5001. Been working well, and I still owe Kevin a beer for that one... :)
From: Kevin Gibbs [mailto:kgibbs --at-- ncsa.uiuc.edu]
Sent: Tuesday, October 28, 2003 3:02 PM
To: 'iperf-users --at-- dast.nlanr.net'
Subject: RE: multicast problems
On Tue, 28 Oct 2003, Sinada, Yasir wrote:
> Hi Kevin, all
> Thanks for the quick response and asserting my assumptions. I usually do
> these scenarios, and when they fail then I verify them with the authors.
> Here are more unicast & multicast issues (still under previous env, i.e.
> v.1.7 under WIN32)
> 1. Why does the CPU max out (100%) at the client (iperf -c host/ip)?
> Actually this happens even in unicast. It would have made sense to me if it
> were at the listening side (server).
This is due to the way we attempt to provide CBR (Constant Bit Rate) UDP
streams. We do a tight busy waiting loop between packets being sent thus
resulting in 100% (or other high utilization numbers). sleep() and even
usleep() often are not accurate/precise enough to achieve the desired
results. The reason the server does not show this behavior is because it
only wakes up when a packet arrives and sleeps otherwise.
> 2. Can I run/install two servers as services on different ports? for example
> $iperf -s -u -p 5001 -D -o out01
> $iperf -s -u -p 6543 -D -o out05
> knowing that later the services would be removed with
> $iperf -s -u -p 5001 -R
> $iperf -s -u -p 6543 -R
> When I tried that I just got the first one (out01) on port 5001. I tried a
> quick trick (I don't know how services run under win32, yet!) like
> $copy iperf.exe iperf1.exe
> $iperf -s -u -p 5001 -D -o out01
> $iperf1 -s -u -p 6543 -D -o out43
> Looks like it works (got out43) but the (-R) killed both which is not what I
> want (timing issues)
Generally no it is not possible to have two servers as services. This is
because services are keyed on service names which is Constant in the
source as "Iperf Service" I believe. If you compile two different versions
with different service names and descriptions then you could run two at a
> 3. I am assuming it is OK to use --len & --bandwitdh as options on the same
> cmd, right?
Yes changing packet size and setting bandwidth can be done on the same
cmdline. The before mentioned tight loop takes both into account when
determining how long to spin.
> 4. Referring to bullet #3 (the second one) on my previous email (shown
> below), Can I run a duplicate scenario besides the original but on a
> different port, in other words can I do the following on the same PC with
> one NIC (trying to get two parallel media streams out, one on 5009 and the
> other at 6543)
> $perf -s -u -p -P 1 5009 -B 220.127.116.11
(er) $iperf -s -u -P 1 -p 5009 -B 18.104.22.168 (may work better)
> $iperf -s -u -P 1 -p 5009 -B 22.214.171.124
> $iperf -u -b 1K -p 5009 --ttl 5 -t 10 -c 126.96.36.199
> $perf -s -u -P 1 -p 6543 -B 188.8.131.52
> $iperf -s -u -P 1 -p 6543 -B 184.108.40.206
> $iperf -u -b 1K -p 6543 --ttl 5 -t 10 -c 220.127.116.11
Yes this should work. I could have been more specific on the previous
reply, but WIN32 is limited to 1 UDP stream recieved per Port(and I think
per IP address). So as long as you have only one recieving stream (I
think per multicast address per port) per port you should be able to run
as many streams as you want. Just in case I would suggest running
something like this to be sure Windows won't beat up on you.
(server) -p 5001 -B 18.104.22.168
(server) -p 5005 -B 22.214.171.124
(client) -p 5010 -B 126.96.36.199
(server) -p 5011 -B 188.8.131.52
(server) -p 5015 -B 184.108.40.206
(client) -p 5020 -B 220.127.116.11
Then permutate the client around on the other 2 machines.
> -----Original Message-----
> From: Kevin Gibbs [mailto:kgibbs --at-- ncsa.uiuc.edu]
> Sent: Thursday, October 23, 2003 5:18 PM
> To: Sinada, Yasir
> Cc: iperf-users --at-- dast.nlanr.net
> Subject: RE: multicast problems
> > >From: "Sinada, Yasir" <Yasir.Sinada --at-- Marconi.com>
> > >To: "'dast --at-- nlanr.net'" <dast --at-- nlanr.net>
> > >Subject: multicast problems
> > >Date: Wed, 22 Oct 2003 19:57:17 -0400
> > >
> > >Hi,
> > >I am using iperf version 1.7 on WIN32 platform. I had these issues with
> > >multicast:
> > >1. What is the proper order in starting? Is it client first then servers
> > >vice versa?
> With Iperf, servers should always be started before clients. Servers need
> the time to set up and start listening before a client attempts a
> > >2. Does the -P (--parallel) work with the -B option for multicast
> The -P on the server side limits the number of incoming connections
> handled. Unfortunately WIN32 has a HORRIBLE UDP implementation which
> forces WIN32 UDP servers to only be able to handle one connection at a
> time. So if you have only one stream flowing at any given time then the -P
> works fine and will close the server after the given number of
> > >3. Does the -o option work without the -D option? I want to use it
> > >of redirecting the output ( .. > outputfile)
> At this time no. The -o was added for use with the -D, and implemented in
> that narrow outlook. I was not here when WinService was added to Iperf but
> I may change that behavior in a future version. It would also be nice to
> have a portable version of the -o instead of the WIN32 only version we
> have now.
> > >3. Can I bind (-B) to 2 or more different multicast addresses on the same
> > >port, on the same interface (NIC) while sending to a third multicast on
> > >same port, in other words can I do the follwing from 18.104.22.168 with only
> > >NIC (of course these addresses are not the actual ones :o)
> > >>iperf -s -u -p 5009 -i 1 -B 22.214.171.124
> > >>iperf -s -u -p 5009 -i 1 -B 126.96.36.199
> > >>iperf -u -b 1K -p 5009 --ttl 5 -t 10 -c 188.8.131.52
> There should be no reason why this wouldn't work. Be sure however that
> there is only ONE client per Multicast address when using WIN32 servers
> because of the previously mentioned junkie WIN32 UDP support. I see you
> have realized the need for the --ttl option, make sure that the value is
> high enough to reach your servers (but I am guessing you have that under
> control =-).
> PS: Thanks for the extremely well written and informative questions. It is
> nice not to have to guess what people are trying to do or how they are
> trying to do it.