0001122: Over 1000 unnecessary wakeups a second

Notes
(0002310) Wuischke (manager) 2007-06-08 11:03	Does the same happen with amuled?

(0002311) mooninite (reporter) 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 (manager) 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 (reporter) 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 (reporter) 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 (manager) 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 (manager) 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 (reporter) 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 (manager) 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 (manager) 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 (manager) 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 (manager) 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)

Issue History
Date Modified	Username	Field	Change
2007-06-07 17:37	mooninite	New Issue
2007-06-07 17:37	mooninite	Operating System	=> Fedora 7
2007-06-08 11:03	Wuischke	Note Added: 0002310
2007-06-08 20:59	mooninite	Note Added: 0002311
2007-06-09 11:12	Wuischke	Note Added: 0002312
2007-06-09 20:52	mooninite	Note Added: 0002314
2007-06-11 22:30	mooninite	Note Added: 0002316
2007-06-16 09:59	Wuischke	Note Added: 0002320
2007-06-16 10:15	Wuischke	Note Edited: 0002320
2007-06-16 20:05	Wuischke	Note Added: 0002321
2007-06-17 07:29	mooninite	Note Added: 0002322
2007-06-17 08:23	Wuischke	Note Added: 0002323
2007-06-17 09:30	Wuischke	Note Edited: 0002323
2007-06-17 17:27	Wuischke	Status	new => assigned
2007-06-17 17:27	Wuischke	Assigned To	=> Wuischke
2007-06-23 15:21	Wuischke	Note Added: 0002334
2007-06-23 20:10	Wuischke	Note Edited: 0002334
2007-06-24 18:08	Wuischke	Note Added: 0002336
2007-06-24 22:07	Wuischke	Status	assigned => resolved
2007-06-24 22:07	Wuischke	Resolution	open => fixed
2007-06-24 22:07	Wuischke	Note Added: 0002337

Relationships