aMule Bug Tracker - aMule
View Issue Details
0001122aMuleMiscpublic2007-06-07 17:372007-06-24 22:07
mooninite 
Wuischke 
normalminoralways
resolvedfixed 
2.1.3 
 
Fedora 7
0001122: Over 1000 unnecessary wakeups a second
Using the PowerTOP utility from http://www.linuxpowertop.org [^] I am seeing amule as the worst offender when it comes to power usage.

I have aMule running. No transfers going. No uploads going. No shared files. I am simply connected to an eMule server.

Output from PowerTOP:
  75.5% (959.6) amule : do_nanosleep (hrtimer_wakeup)
   7.3% ( 92.2) amule : schedule_timeout (process_timeout)

You may want to investigate this issue to help laptop owners with thier battery life. You will need a 2.6.21 kernel with an i386 CPU and the PowerTOP utility.

My System:
Fedora 7
Kernel 2.6.21
No tags attached.
Issue History
2007-06-07 17:37mooniniteNew Issue
2007-06-07 17:37mooniniteOperating System => Fedora 7
2007-06-08 11:03WuischkeNote Added: 0002310
2007-06-08 20:59mooniniteNote Added: 0002311
2007-06-09 11:12WuischkeNote Added: 0002312
2007-06-09 20:52mooniniteNote Added: 0002314
2007-06-11 22:30mooniniteNote Added: 0002316
2007-06-16 09:59WuischkeNote Added: 0002320
2007-06-16 10:15WuischkeNote Edited: 0002320
2007-06-16 20:05WuischkeNote Added: 0002321
2007-06-17 07:29mooniniteNote Added: 0002322
2007-06-17 08:23WuischkeNote Added: 0002323
2007-06-17 09:30WuischkeNote Edited: 0002323
2007-06-17 17:27WuischkeStatusnew => assigned
2007-06-17 17:27WuischkeAssigned To => Wuischke
2007-06-23 15:21WuischkeNote Added: 0002334
2007-06-23 20:10WuischkeNote Edited: 0002334
2007-06-24 18:08WuischkeNote Added: 0002336
2007-06-24 22:07WuischkeStatusassigned => resolved
2007-06-24 22:07WuischkeResolutionopen => fixed
2007-06-24 22:07WuischkeNote Added: 0002337

Notes
(0002310)
Wuischke   
2007-06-08 11:03   
Does the same happen with amuled?
(0002311)
mooninite   
2007-06-08 20:59   
I'm using the RPM from freshrpms.net, which does not include "amuled" so I cannot test it.
(0002312)
Wuischke   
2007-06-09 11:12   
There's a package with amuled in the forums, could you please try with this one?
http://forum.amule.org/index.php?topic=12762.msg68140#msg68140 [^]

I'll do some testing as soon as I can get hold of a Linux powered computer, probably next week Friday, when I'm back home.
(0002314)
mooninite   
2007-06-09 20:52   
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. :)
(0002316)
mooninite   
2007-06-11 22:30   
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
(0002321)
Wuischke   
2007-06-16 20:05   
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.
(0002322)
mooninite   
2007-06-17 07:29   
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
(0002336)
Wuischke   
2007-06-24 18:08   
See http://forum.amule.org/index.php?topic=12863.0 [^] for an experimental patch.

Further improvements to the core_timer are to be expected as well.
(0002337)
Wuischke   
2007-06-24 22:07   
I've commited a fix to solve the issue. (Which is not identical to the patch posted in the forums)