100% CPU Usage w/0.5.8 + Speed Limiter Plugin

[Guru]

Just downloaded Deluge 0.5.8 for Ubuntu 7.10 (Gutsy) 64-bit and whenever I enable the speed limiter plugin to anything other than "Unilimited" the CPU usage rockets to 100%...

This is very strange, because it is the same behavior that I saw in the older v.0.5.6.2; however, I was able to use the Speed Limiter plugin in version 0.5.7 without a problem, but it appears that the latest Deluge has a regression.

Any suggestions? I already tried deleting the .config/deluge directory, but it didn't make any difference. Obviously running w/o the speed limiter plugin, or with the plugin set to unlimited in both directions works fine.

[markybob]

Just downloaded Deluge 0.5.8 for Ubuntu 7.10 (Gutsy) 64-bit and whenever I enable the speed limiter plugin to anything other than "Unilimited" the CPU usage rockets to 100%...

This is very strange, because it is the same behavior that I saw in the older v.0.5.6.2; however, I was able to use the Speed Limiter plugin in version 0.5.7 without a problem, but it appears that the latest Deluge has a regression.

Any suggestions? I already tried deleting the .config/deluge directory, but it didn't make any difference. Obviously running w/o the speed limiter plugin, or with the plugin set to unlimited in both directions works fine.

does this happen only with download limit, or only with upload limit, or both?

[Elahrairah]

Hi

I've noticed the same, but with deluge running with windows..

Last night i enabled the download limit plugin, At the time i have 3 downloads running, so i right clicked the first, set a d/l limit and then an u/l limit, I then did the same for the second download but strangely, anytime i tried to change the third thing i have downloading, Deluge just crashed.. I couldnt access Deluge from then on to change the setting because everytime i tried to do something on it to cancel the settings, it just froze again.. To resolve the issue i have to delete deluge and start again..

Regards
Elahrairah

[markybob]

Hi

I've noticed the same, but with deluge running with windows..

Last night i enabled the download limit plugin, At the time i have 3 downloads running, so i right clicked the first, set a d/l limit and then an u/l limit, I then did the same for the second download but strangely, anytime i tried to change the third thing i have downloading, Deluge just crashed.. I couldnt access Deluge from then on to change the setting because everytime i tried to do something on it to cancel the settings, it just froze again.. To resolve the issue i have to delete deluge and start again..

Regards
Elahrairah

i think i've figured this out...i hope so, anyway should be fixed in svn and will be in the next release.

[Elahrairah]

No worries,

Great work so far, thanks

Regards
Elahrairah

[skeptikone]

I am also having a similar problem, except using ubuntu hardy, version 0.5.8. I have disabled all plugins and it is still using 100% cpu.This only happens while torrents are running, when they are paused cpu usage returns to normal.

[markybob]

I am also having a similar problem, except using ubuntu hardy, version 0.5.8. I have disabled all plugins and it is still using 100% cpu.This only happens while torrents are running, when they are paused cpu usage returns to normal.

did you build your own, or did you install via our deb package?

[skeptikone]

the deb package from you guys.

[skeptikone]

i've discovered its only whilst downloading also, not while just seeding only, if that helps.. (ie paused all downloading torrents and left seeding ones running)

[markwright]

Hi, Yesterday with 0.5.8 final on Solaris 10u6 dual Opteron box with upload
speed limit set, no download limit, that gnome 2.20.1 System Monitor said
that Deluge was taking about 65% CPU (there are 2 CPUs, while System Monitor
itself is greedy taking the other 35%), which resulting in Xine skipping
trying to listen to music. So I nice'd both of those which allowed Xine to
play music uninterrupted.

Today since markybob said he'd tweaked something that might hopefully fix it,
I tried looking at what had changed in svn recently, and tried applying these
diffs from svn to 0.5.8:

svn diff -r 2503:2504 deluge

(Ignoring that the changes to deluge/libtorrent/src/peer_connection.cpp were
rejected). Then rebuilt it, and it seems a lot better, as in only very
very occassionally observed by System Monitor to consume 50 - 65% CPU for
probably less than a second. I tried capturing some pstack traces of
this brief period of CPU use (with the above change applied), most of
the time the thread that was running is:

----------------- lwp# 3 / thread# 3 --------------------
fec859c8 __clock_gettime (4, fa888808, fa888828) + 28
fb29c137 libtorrent::ptime libtorrent::time_now() (fa888848, 0) + 23
fb2fae94 libtorrent::ptime asio::time_traits<libtorrent::ptime>::now() (fa888878, 0) + 20
fb2fa4df boost::posix_time::time_duration asio::detail::timer_queue<asio::time_traits<libtorrent::ptime> >::wait_duration()const (fa8888b0, 845b144) + 1f
fb2d354c int asio::detail::dev_poll_reactor<false>::get_timeout() (845f0e8, 8cd47f8, 0, fb2d24c3) + 88
fb2d2603 void asio::detail::dev_poll_reactor<false>::run(bool) (845f0e8, 1, 83ff1f8, fb31a59a) + 2a7
fb31a6ff unsigned asio::detail::task_io_service<asio::detail::dev_poll_reactor<false> >::do_one(asio::detail::scoped_lock<asio::detail::posix_mutex>&,asio::detail::task_io_service<asio::detail::dev_poll_reactor<false> >::idle_thread_info*,asio::error_code&) (83ff1f8, fa888e68, fa888e70, fa888ec8) + 173
fb318b6e unsigned asio::detail::task_io_service<asio::detail::dev_poll_reactor<false> >::run(asio::error_code&) (83ff1f8) + 6e
fb31396a unsigned asio::io_service::run() (8459578, 8459400, 1, fb306c2e) + 32
fb306cad void libtorrent::aux::session_impl::operator()() (8459400, fa888fb4, 0, fb322350) + 8d
fb322365 void boost::detail::function::void_function_ref_invoker0<libtorrent::aux::session_impl,void>::invoke(boost::detail::function::function_buffer&) (fa888fb4, 8045730, 0, 0) + 21
faca5128 ???????? (80455b0)
fec84662 _thr_setup (fa770000) + 4e
fec84950 _lwp_start (fa770000, 0, 0, fa888ff8, fec84950, fa770000)

But I don't really know if the above change has anything to do with this
or not, so just ignore me if it doesn't.

Thanks, Mark