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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerrit Renker Sent: Friday, May 02, 2008 4:05 PM To: Upakul Barkakaty Cc: [EMAIL PROTECTED] 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 <[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&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 <[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/j avaone _______________________________________________ Iperf-users mailing list Iperf-users@lists.sourceforge.net 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iperf-users
