Hi,

I've upgraded my box to openSUSE 11.3 (64bit) which comes with KTorrent 3.3.4. I used that version for a few days but decided to remove it and compile 4.0.2 myself. All went fine but the CPU usage in this version is really high. My settings are reasonable (and haven't changed for a long time) but running 3 torrents at the same time, my CPU usage is about 50%, all being sucked by KTorrent. In version 3.3.4, the CPU usage was far lower, something like 10% or so. Because of this, I'm thinking going back to 3.3.4. I tried setting main transport to TCP and then to uTP, but same remains. Very high CPU usage

Specs:

openSUSE 11.3 (64bit)
KDE4 4.4.4
QT 4.6.3

First I have heard of CPU usage problems in 4.0.2.

What version of libktorrent are you using ?

Hi George

I'm using the one shipped with 4.0.2, which is 1.0.2. I should say that I have about 70 torrents in ktorrent, but most are seedings with no connected leechers (this is pretty "normal" for torrents from torrentech).

The three active torrents I was talking about, had a download speed of about 200KB/s each, with about 100-150 peers connected each. The CPU for me was about 50%. Switching over to qBittorrent with the same torrents, the CPU was only 5% or so

What happens if you only start one or two of those 3 active torrents ?

If I start only one torrent, according to top, the CPU is only a few percentages. If I start the second torrent too (and wait a while until it settles), CPU increases to about 10-15%, and if I start the third one (and wait a bit until all settles), CPU reaches at times 50%, but usually stays steady at 35-40%.

I've always found that ktorrent, out of all clients I've tried/investigated, is the one using too much CPU time, especially when a lot of peers are connected and the download speed is pretty high. Last time I was doing my small "tests" here on a torrent with ~1MB/s download speed, ktorrent definitely lost against qbittorrent when it comes to CPU usage. I can't tell you if this is due to the high download speed of the torrent, due to the amount of peers connected or a combination of both, but one thing is for sure. qBittorrent always uses less CPU resources on high speed/lots-of-peers torrents than ktorrent does. And it's not on just this machine as I also tried it on my lappy and got the same results. I keep my configurations (ie, max peers per torrent, max global connections, ports, etc) in sync across my few clients I use and these tests are not advanced ones but ones where I just look at CPU utilization while running the same torrents in different clients (not at the same time).

I too consider that the CPU usage is high (compared to the Windows days with utorrent). It usually stays at 10-15 with a Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz.

Try disabling uTP.

A few svns later and uTP disabled and I have these results:

15 torrents seeding (mostly idling actually)

- with KT minimized in the taskbar CPU usage is 5-10%
- with KT maximized CPU usage goes up to 20 even 25%

Both values seem high to me (am I picky or not? ) but what can I say? The second case (KT maximized) seems to be a general problem in Linux (KDE aggravates it) that the GUI is consuming much more than one would think. (personal opinion see notes bellow)

Notes:
KDE 4.5 RC2
Nvidia card with nouveau driver so no compositing or 3D acceleration.

roentgen wrote: that the GUI is consuming much more than one would think

I experimented with 500 ms GUI refresh setting in Ktorrent, and my CPU jump to 20-25% for only 4 active torrents while Ktorrent window is maximized and uTP enabled.

I generally use a GUI refresh of 2 seconds (2000ms) no matter what bittorrent client I've used (uTorrent, qBittorrent, and especially for Vuze). With a Ktorrent GUI refresh setting of 2000 ms and the window being minimized, my CPU is about 5% with 4 active torrents and uTP enabled, so that is making me believe that the GUI's redraw/repaint code should be the first thing to investigate.

Indeed, I had it at 1000ms (I played with it but I forgot). With 2000ms seems OK now (i.e. 2-4 max 10% CPU). Thanks for the hint.

The GUI is heavy because it shows a lot of information. The update interval was made configurable because of it.