Re: Iperf Transmit leading to 100% CPU Utilization

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: Iperf Transmit leading to 100% CPU Utilization

Dear Upakul,

if it is not too much of a bother, can you please check if the attached
patch fixes the CPU usage problem?

It is a port of Ingo Molnar's CPU usage fix - we have used that patch in
iperf with great benefit (the CPU usage went down to very modest values).

Regards
Gerrit

Quoting Upakul Barkakaty:
|    Hi Jon,
| 
|    I have upgraded to Iperf-v2.0.4. But unfortunately, even with this version
|    I observed that the Iperf client was consuming all the CPU MIPS even if it
|    was running at 1 Mbps.
| 
|    --
|    Regards,
|    Upakul Barkakaty
| 
|    On 4/23/08, Jon Dugan <jdugan@...> wrote:
| 
|      Upakul,
| 
|      Which version of Iperf are you using?  This should be resolved in Iperf
|      MailScanner warning: numerical links are often malicious: 2.0.4.
| 
|      Jon
| 
|      Upakul Barkakaty wrote:
| 
|        Hi all,
| 
|        I was using the Iperf UDP client to test the network bandwidth and CPU
|        Utilization. I observed that the Iperf client was consuming all the
|        CPU MIPS even if it was running at 1 Mbps.
| 
|        On investigation, It looks like the delay_loop() function in the file
|        Client.cpp is blocking in the kernel space while adjusting the
|        thoughput speeds. On trying out replacing delay_loop() by usleep()
|        function, Idle MIPS were available.
| 
|        Please can you let me know if this is an intended behaviour keeping in
|        mind some particular purpose?
| 

The University of Aberdeen is a charity registered in Scotland, No SC013683.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: Iperf Transmit leading to 100% CPU Utilization

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: Iperf Transmit leading to 100% CPU Utilization

Upakul,

thank you for testing. So it seems the problem is not in this corner. I
also recall comparing the performance of iperf 2.0.4 against 2.0.2 with
that patch - Jon has added some condition variables, which seem to have
a similar effect (testing with 2.0.4 also gave modest CPU usage).

With regard to the delay loop, the high CPU consumption seems clear
since delay_loop() constantly calls gettimeofday(), i.e. issueing the
same system call over and over again in a busy-wait loop. Which agrees
with your analysis.

I have had problems with this, too, but in a different corner: when
measuring the actual times, delay_loop() sometimes added something like
50 milliseconds at random times, which seems like a quantum for a
context switch.

It got much better when replacing the busy-wait loop with a call to the
Posix function nanosleep(), since this uses hrtimers internally and
blocks signals.

Although the patch was initially not intended to reduce CPU usage, I
could well imagine that it does since removes the busy-wait loop.

If you have a moment of time, could you check out whether this makes a
difference -- it is in the repository, on

https://sourceforge.net/tracker/index.php?func=detail&aid=1940009&group_id=128336&atid=711373

Best regards
Gerrit

Quoting Upakul Barkakaty:
|    Hi Gerrit,
| 
|    Thanks a lot for your reply. I indeed tried out the patch but it did not
|    make any difference. I am still seeing 0% CPU Idle.
| 
|    It looks to me as if the delay_loop() function in the file Client.cpp is
|    holding the processor in the kernel space while adjusting the thoughput
|    speeds, resulting in 0% CPU Idle. On trying out replacing delay_loop() by
|    usleep() function, Idle MIPS were seen to be available. Or perhaps is it
|    the case that iperf should be used only for throughput measurement and
|    might not be so appropriate for measuring the cpu utilization?
| 
|    --
|    Regards,
|    Upakul Barkakaty
| 
|    On 5/2/08, Gerrit Renker <gerrit@...> wrote:
| 
|      Dear Upakul,
| 
|      if it is not too much of a bother, can you please check if the attached
|      patch fixes the CPU usage problem?
| 
|      It is a port of Ingo Molnar's CPU usage fix - we have used that patch in
|      iperf with great benefit (the CPU usage went down to very modest
|      values).
| 
|      Regards
|      Gerrit
| 
|      Quoting Upakul Barkakaty:
|      |    Hi Jon,
|      |
|      |    I have upgraded to Iperf-v2.0.4. But unfortunately, even with this
|      version
|      |    I observed that the Iperf client was consuming all the CPU MIPS
|      even if it
|      |    was running at 1 Mbps.

The University of Aberdeen is a charity registered in Scotland, No SC013683.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: Iperf Transmit leading to 100% CPU Utilization

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: bidirectional test fails because of firewall

I'm looking for a tool to measure bandwidth that can do it in both
directions. I want my server to be running on a public server, but the
client to be running behind NAT. Can iperf do this?

Marc Herbert <marc.herbert <at> gm...> wrote on 2008-04-22 20:55:
> It seems that with iperf, the connecting/initiating side is always the
> data sending side. Both for upstream and downstream tests.

Is this really true? I would have thought this would be *the* nr 1 use
of iperf: To measure download speed on a NAT'ed ADSL connection, where
sockets *only* can be opened in the client->server direction.

So: Is there any way to test the server->client direction on a socket
opened by the client thus enabling testing from behind NAT? If not, are
there any patches around that do that? Would it be tricky to do?
Otherwise, does anybody know of any other tools on linux that would let
me test my upload and download speeds?

An alternative is to use SSH port forwarding:

TERMINAL 1:
ssh -L 5201:localhost:5201 -R 5202:localhost:5202 server.tld iperf -s -p
5201

TERMINAL 2:
iperf -c localhost -r -p 5201 -L 5202

Now of course all traffic is running inside ssh tunnels. Would that give
meaningful results? What should I keep in mind when interpreting these
results (that happen to be "roughly" what I was expecting). It is a
*mess* to automate this and kill the server process correctly at the
right time... Anybody done this successfully? (A script suggestion at 
end of this mail)

Peter

P.S.: Sorry if the message doesn't show up threaded properly. I just
joined this list and thus don't have the original message. I just
cut'n'pasted the title.

<code filename="iperf-ssh">
#!/bin/bash
server=$1

# Ok, so the port numbers are hardcoded for now
# Remove the  >/dev/null 2>&1  from the line below if you
# experience problems
ssh -L 5201:localhost:5201 -R 5202:localhost:5202 $server iperf -s -p 
5201 >/dev/null 2>&1 &

# This is the pid of ssh, not remote pid for iperf...
# pid=$!
# echo "pid" $pid

# Let the remote iperf process start up properly
sleep 5

iperf -c localhost -r -p 5201 -L 5202

# This would only kill the ssh process. If we kill ssh, iperf is still
# left
# running on remote host.  Aaarhhh - that doesn't work
# kill $pid

# Instead, ssh to $server and kill all iperf processes.  Yes it is a
# mess, but
# there is no easy way to figure out the right process ID of the server
# process.
ssh $server killall iperf
</code>
--

-- 
Peter Valdemar Mørch
http://www.morch.com

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: Iperf Transmit leading to 100% CPU Utilization

Thank you for testing. After this email I also checked again:

  * with the old busy-wait loop, there are three threads, and one is
    always close to 100% (I think that is the one you mean);

  * using either of select() or nanosleep() to replace the delay_loop()
    reduces the number of threads to 2 (the usage is still quite high,
    between 80% and 90%).

I will tidy the patch up, in earlier tests using nanosleep() had
in addition the best resolution.

Gerrit

Quoting Upakul Barkakaty:
|    Hi Gerrit,
| 
|    Thanks a lot. This patch has really helped.
| 
|    --
|    Regards,
|    Upakul Barkakaty
| 
|    On 5/2/08, Gerrit Renker <gerrit@...> wrote:
| 
|      Upakul,
| 
|      thank you for testing. So it seems the problem is not in this corner. I
|      also recall comparing the performance of iperf 2.0.4 against 2.0.2 with
|      that patch - Jon has added some condition variables, which seem to have
|      a similar effect (testing with 2.0.4 also gave modest CPU usage).
| 
|      With regard to the delay loop, the high CPU consumption seems clear
|      since delay_loop() constantly calls gettimeofday(), i.e. issueing the
|      same system call over and over again in a busy-wait loop. Which agrees
|      with your analysis.
| 
|      I have had problems with this, too, but in a different corner: when
|      measuring the actual times, delay_loop() sometimes added something like
|      50 milliseconds at random times, which seems like a quantum for a
|      context switch.
| 
|      It got much better when replacing the busy-wait loop with a call to the
|      Posix function nanosleep(), since this uses hrtimers internally and
|      blocks signals.
| 
|      Although the patch was initially not intended to reduce CPU usage, I
|      could well imagine that it does since removes the busy-wait loop.
| 
|      If you have a moment of time, could you check out whether this makes a
|      difference -- it is in the repository, on
| 
|      https://sourceforge.net/tracker/index.php?func=detail&aid=1940009&group_id=128336&atid=711373
| 
|      Best regards
| 
|      Gerrit
| 
|      Quoting Upakul Barkakaty:
|      |    Hi Gerrit,
|      |
|      |    Thanks a lot for your reply. I indeed tried out the patch but it
|      did not
|      |    make any difference. I am still seeing 0% CPU Idle.
|      |
|      |    It looks to me as if the delay_loop() function in the file
|      Client.cpp is
|      |    holding the processor in the kernel space while adjusting the
|      thoughput
|      |    speeds, resulting in 0% CPU Idle. On trying out replacing
|      delay_loop() by
|      |    usleep() function, Idle MIPS were seen to be available. Or perhaps
|      is it
|      |    the case that iperf should be used only for throughput measurement
|      and
|      |    might not be so appropriate for measuring the cpu utilization?
|      |
|      |    --
|      |    Regards,
|      |    Upakul Barkakaty
|      |
|      |    On 5/2/08, Gerrit Renker <gerrit@...> wrote:
|      |
|      |      Dear Upakul,
|      |
|      |      if it is not too much of a bother, can you please check if the
|      attached
|      |      patch fixes the CPU usage problem?
|      |
|      |      It is a port of Ingo Molnar's CPU usage fix - we have used that
|      patch in
|      |      iperf with great benefit (the CPU usage went down to very modest
|      |      values).
|      |
|      |      Regards
|      |      Gerrit
|      |
|      |      Quoting Upakul Barkakaty:
|      |      |    Hi Jon,
|      |      |
|      |      |    I have upgraded to Iperf-v2.0.4. But unfortunately, even
|      with this
|      |      version
|      |      |    I observed that the Iperf client was consuming all the CPU
|      MIPS
|      |      even if it
|      |      |    was running at 1 Mbps.
| 
|      The University of Aberdeen is a charity registered in Scotland, No
|      SC013683.
| 
|    The University of Aberdeen is a charity registered in Scotland, No
|    SC013683.

--

-- 

The University of Aberdeen is a charity registered in Scotland, No SC013683.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

-n option

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: Iperf Transmit leading to 100% CPU Utilization

Hi Gerrit,
Running 2.0.4 version produced in TCP runs much better BW in medium size
messages. (340 MB/sec vs 40 MB/sec at 128 bytes msg and 4 processes)
But the cpu usage rises as well at these area (from 10% to 45%).
Applying both the above patches do not improve cpu usage.

Should I expect a cpu usage reduction, or is it the price for the
improved BW ?

Thanks, 

Oren   Meron
Performance

-----Original Message-----
From: iperf-users-bounces@...
[mailto:iperf-users-bounces@...] On Behalf Of Gerrit
Renker
Sent: Friday, May 02, 2008 4:05 PM
To: Upakul Barkakaty
Cc: iperf-users@...
Subject: Re: [Iperf-users] Iperf Transmit leading to 100% CPU
Utilization

Thank you for testing. After this email I also checked again:

  * with the old busy-wait loop, there are three threads, and one is
    always close to 100% (I think that is the one you mean);

  * using either of select() or nanosleep() to replace the delay_loop()
    reduces the number of threads to 2 (the usage is still quite high,
    between 80% and 90%).

I will tidy the patch up, in earlier tests using nanosleep() had in
addition the best resolution.

Gerrit

Quoting Upakul Barkakaty:
|    Hi Gerrit,
| 
|    Thanks a lot. This patch has really helped.
| 
|    --
|    Regards,
|    Upakul Barkakaty
| 
|    On 5/2/08, Gerrit Renker <gerrit@...> wrote:
| 
|      Upakul,
| 
|      thank you for testing. So it seems the problem is not in this
corner. I
|      also recall comparing the performance of iperf 2.0.4 against
2.0.2 with
|      that patch - Jon has added some condition variables, which seem
to have
|      a similar effect (testing with 2.0.4 also gave modest CPU usage).
| 
|      With regard to the delay loop, the high CPU consumption seems
clear
|      since delay_loop() constantly calls gettimeofday(), i.e. issueing
the
|      same system call over and over again in a busy-wait loop. Which
agrees
|      with your analysis.
| 
|      I have had problems with this, too, but in a different corner:
when
|      measuring the actual times, delay_loop() sometimes added
something like
|      50 milliseconds at random times, which seems like a quantum for a
|      context switch.
| 
|      It got much better when replacing the busy-wait loop with a call
to the
|      Posix function nanosleep(), since this uses hrtimers internally
and
|      blocks signals.
| 
|      Although the patch was initially not intended to reduce CPU
usage, I
|      could well imagine that it does since removes the busy-wait loop.
| 
|      If you have a moment of time, could you check out whether this
makes a
|      difference -- it is in the repository, on
| 
|      
| https://sourceforge.net/tracker/index.php?func=detail&aid=1940009&grou
| p_id=128336&atid=711373
| 
|      Best regards
| 
|      Gerrit
| 
|      Quoting Upakul Barkakaty:
|      |    Hi Gerrit,
|      |
|      |    Thanks a lot for your reply. I indeed tried out the patch
but it
|      did not
|      |    make any difference. I am still seeing 0% CPU Idle.
|      |
|      |    It looks to me as if the delay_loop() function in the file
|      Client.cpp is
|      |    holding the processor in the kernel space while adjusting
the
|      thoughput
|      |    speeds, resulting in 0% CPU Idle. On trying out replacing
|      delay_loop() by
|      |    usleep() function, Idle MIPS were seen to be available. Or
perhaps
|      is it
|      |    the case that iperf should be used only for throughput
measurement
|      and
|      |    might not be so appropriate for measuring the cpu
utilization?
|      |
|      |    --
|      |    Regards,
|      |    Upakul Barkakaty
|      |
|      |    On 5/2/08, Gerrit Renker <gerrit@...> wrote:
|      |
|      |      Dear Upakul,
|      |
|      |      if it is not too much of a bother, can you please check if
the
|      attached
|      |      patch fixes the CPU usage problem?
|      |
|      |      It is a port of Ingo Molnar's CPU usage fix - we have used
that
|      patch in
|      |      iperf with great benefit (the CPU usage went down to very
modest
|      |      values).
|      |
|      |      Regards
|      |      Gerrit
|      |
|      |      Quoting Upakul Barkakaty:
|      |      |    Hi Jon,
|      |      |
|      |      |    I have upgraded to Iperf-v2.0.4. But unfortunately,
even
|      with this
|      |      version
|      |      |    I observed that the Iperf client was consuming all
the CPU
|      MIPS
|      |      even if it
|      |      |    was running at 1 Mbps.
| 
|      The University of Aberdeen is a charity registered in Scotland,
No
|      SC013683.
| 
|    The University of Aberdeen is a charity registered in Scotland, No
|    SC013683.

-- 

The University of Aberdeen is a charity registered in Scotland, No
SC013683.

------------------------------------------------------------------------
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't
miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Re: bidirectional test fails because of firewall

2008/5/2, "Peter Valdemar Mørch (Lists)" <4ux6as402@...>:
>
>  Marc Herbert <marc.herbert <at> gm...> wrote on 2008-04-22 20:55:
>  > It seems that with iperf, the connecting/initiating side is always the
>  > data sending side. Both for upstream and downstream tests.
>
>  Is this really true?

Read the source?

> I would have thought this would be *the* nr 1 use
>  of iperf: To measure download speed on a NAT'ed ADSL connection, where
>  sockets *only* can be opened in the client->server direction.

You have to keep in mind that NATs are a kludge and that there is
nothing mandating network applications to take them into
consideration.

>  So: Is there any way to test the server->client direction on a socket
>  opened by the client thus enabling testing from behind NAT?

The easiest solution I can think of is the usual one for NAT: setup
port forwarding to a given NATed address. I think every NAT device
allows that.

> If not, are  there any patches around that do that? Would it be tricky to do?

Since both testing directions are already implemented, I guess it
should not be that hard.

>  Now of course all traffic is running inside ssh tunnels. Would that give
>  meaningful results? What should I keep in mind when interpreting these
>  results (that happen to be "roughly" what I was expecting).

I would say that it stays meaningful as long as throughput is small
enough for encryption not to hog the CPU(s). Say a few tenths of Mb/s.

Cheers,

Marc.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users