|
Notes |
|
|
|
|
Does the same happen with amuled? |
|
|
|
|
|
I'm using the RPM from freshrpms.net, which does not include "amuled" so I cannot test it. |
|
|
|
|
|
|
|
|
Sure, I will retry this on Monday.
Fedora 7 offers a LiveCD. If you can download 700megs and burn it to CD then you can use any computer. :) |
|
|
|
|
OK, I am now using the new RPM that you linked to. amule-cvs20070606_F7_i386.rpm
This is with amule running:
73.3% (988.8) amule : do_nanosleep (hrtimer_wakeup)
7.0% ( 94.8) amule : schedule_timeout (process_timeout)
I then closed amule and started amuled.
This is amuled running:
74.6% (989.0) amuled : do_nanosleep (hrtimer_wakeup)
7.8% (103.2) amuled : schedule_timeout (process_timeout)
Looks like they both exhibit a large amount of wake ups.
amule was not even connected to a eDonkey server. No shared files. No transfers. |
|
|
|
(0002320)
|
|
Wuischke
|
2007-06-16 09:59
(edited on: 2007-06-16 10:15) |
|
OK, this is very easy explained, but solving this properly might be beyond my scope.
Explanation: aMule has a main loop and checks for several things inside this main loop. It does this a bit less than x (not 1000) times a second, which explains the wake-ups.
I'll try to provide an experimental patch to reduce the number of wake ups, primarily by lowering the timer intervals within a couple of days.
---
I've about 80 wakeups, with a couple of shared files and one active download.
edited on: 06-16-07 10:15 |
|
|
|
|
OK, things seem to be more complicated than I thought.
powertop reports 250+65 wakeups for aMule in idle state resulting in a value of 345 total.
Wakeups-from-idle per second : 345.3
no ACPI power usage estimate available
Top causes for wakeups:
44.4% (249.6) amule : do_nanosleep (hrtimer_wakeup)
11.4% ( 64.1) amule : schedule_timeout (process_timeout)
10.9% ( 61.1) <interrupt> : radeon@pci:0000:01:00.0
10.6% ( 59.8) amarokapp : schedule_timeout (process_timeout)
10.1% ( 56.8) <interrupt> : ipw2200, HDA Intel
5.3% ( 29.9) X : do_setitimer (it_real_fn)
After shutting aMule down, there's still a total value of about 300, indicating that powertop does not calculate the real value for aMule only, but for more than one application while "blaming" amule. This explains the significantly higher value (250+70 compared to 80) compared to my prior tests without/less background programs.
Wakeups-from-idle per second : 303.4
no ACPI power usage estimate available
Top causes for wakeups:
29.5% ( 97.5) amarokapp : schedule_timeout (process_timeout)
26.6% ( 87.7) <interrupt> : radeon@pci:0000:01:00.0
17.2% ( 56.8) <interrupt> : ipw2200, HDA Intel
8.4% ( 27.9) X : do_setitimer (it_real_fn)
6.3% ( 20.8) <interrupt> : extra timer interrupt
3.0% ( 10.0) geany : schedule_timeout (process_timeout)
I have hardly any daemons running, while there are pidgin, xchat2, 3 Terminal windows, geany, opera and amarok opened in the background in an XFCE session.
aMule should have a value slightly higher than 50 according to GetTickCount.cpp - wxTimer implementation. I'll have some more tests with a "purer" environment (no background programs, DRI disabled, WLAN shut down,...), but in general I don't believe that aMule is such a bad offender as you believe. |
|
|
|
|
Please don't assume things about PowerTOP... It only reports the top 6 offending items. If you read their website they show a list of offending programs (and even kernel drivers) that have been reported and have patches. It might be best to start with a wide open mind and look at some of the patches. Pidgin, as you stated you run, has had a tick patch.
I only posted the amule stats. I also run XFCE as my DE, however, aMule was the top offender when I was running PowerTOP. The rest of my list was my nVidia driver, which has an unnecessary tick rate equal to my refresh rate (as your ATI card fglrx driver also has) and items in the 10-20 tick range.
Seeing aMule close to the 1000 mark while completely idle (no connections period) is rather strange in my opinion. |
|
|
|
(0002323)
|
|
Wuischke
|
2007-06-17 08:23
(edited on: 2007-06-17 09:30) |
|
Please compare the values when running aMule idle and without aMule and tell me the difference.
I just fail to believe, that aMule has 250+65 wakeups if the total value is 345 (which means that 345-(250+65)= 30! should be the wakeup from other applications), above all when I've still a value of about 300 after shutting aMule down.
I did not say that I'm not willing to do further research and optimize aMule if possible (don't you worry), but I would like to finish some things regarding skins and userfriendliness in time for aMule 2.2.0, if this issue has a lower priority (i.e. not 1000 real wake ups).
---
OK, I have a kernel with NO_HZ-Option set and therefore "wakeup scheduling". When running in a minimal system (about 40-45 wakeups, minimal xserver), I get the same 250 do_nanosleep wakeups for aMule, which are at the same time the total value. aMule will according to this wakeup 250 times a second, my Kernel has PREEMPT_VOLUNTARY enabled and a timer frequency of 250Hz. I can only assume that your kernel has a timer frequency of 1000Hz, which might explain the significantly higher number. This is in every case inacceptable. (and I'll try to fix it.)
edited on: 06-17-07 09:30 |
|
|
|
(0002334)
|
|
Wuischke
|
2007-06-23 15:21
(edited on: 2007-06-23 20:10) |
|
I've been doing further research, now running a nice 2.6.22-rc5-hrt1 kernel. (now with 1000Hz and therefore about 1000 wakeups as well.)
I've checked all the timers in idle mode (there are 3 I know of, one called by StartTickTimer() in the OnInit()-function in amule.cpp, and core_timer and gui_timer in amule-gui.cpp and amuleDlg.cpp), but they are doing their job as expected.
I have to find the origin of the nanosleep() calls, then I'll try to fix it.
---
Found the source of the wakeups, it's UBT (UploadBandwithThrottler)...something sensitive to play with, I'll have to do more testing and experimenting to improve the situation.
edited on: 06-23-07 20:10 |
|
|
|
|
|
|
|
|
|
I've commited a fix to solve the issue. (Which is not identical to the patch posted in the forums) |
|