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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
