Deluge Forum

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.

Guru wrote: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?

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

Elahrairah wrote: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.

No worries,

Great work so far, thanks

Regards
Elahrairah

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.

skeptikone wrote: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?

the deb package from you guys.

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)

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