Every minute (quite precise), my ktorrent hangs for about 15 seconds. All other applications are responsive. This also smuthers my running connections, which have to speed up again when ktorrent comes back to life. With iotop, during this hanging period, I can see ktorrent going to 99.99% but no disk writes.

ktorrent-3.3.2, writing data to a USB2-attached disk.

Does it also happen if you do not write to an external USB disk ?

Hi.
I do also have this problem,if its the same..
The problem is : when I do bring up the ktorrent window it takes over 10 seconds sometimes for it to respond,
and before the updates (I guess) it was not like that at ALL. I to write to an external usb-disk,but as said:
it was never a problem before,so this problem is either Fedora`s fault or the newest update from ktorrent.
And I will add that NO I have no problem what so ever to write to the same hard drive at all in other software.

I wish I did never update it now. Please please fix this problem quick,I like ktorrent and don`t want to change client.

Thanks for good software so far,but this of course was a step down.

Best regards.

-H

To add a bit more.

Now it has taken ktorrent over 5 minutes to react to my action to open a torrent. That is to long time.
What causes these problems I really have no idea,but I might suspect that this is a problem with Fedora 11,
but I have now way to find that out for sure at this moment. I will upgrade to Fedora 12 when I can,but I
have to live with this to the torrents are finish. Who knows,it might be fixed before I have changed Fedora version.

I will BTW also check if it is like this when writing only to the internal hard drive,but I would need to wait until the started
torrents are finish writing on the USB2 external H.D .

To sum it all up: When I just got Fedora 11 in it was not like this,but I guess that an update went wrong.

-H

New uptdate on this issue:
Well,now its just ok.. without me doing nothing to make this happen.
It reacts fast again,and everything just works like it should.
I don`t know if there has been any update when I was asleep,but if it works like this after a
reboot I guess it has..

Will report more if something more happens,but lets hope not.


Regards.
-H

Hi again.
Even if nobody have replied to my posts here I will continue and reporting in case it helps.

Then back to topic.

Its back! Now ktorrent even uses a whole lot of my cpu. This is just weird.
What is wrong with ktorrent these days? It did work so fine,and then "crash" ...

I am going to reboot my computer now,and then try again.

New updates will follow.

-Harakiri

Well people,ktorrent does not work any longer as it should.
I am out of ideas here. Is there anyone who knows what this is?

It hangs for several minutes from time to time. It would take years to make ktorrent
useful for me now since it stops writing to the disk.

-H

Hi again.
Well.. I have been searching for this problem for a while,but started to use Torrentflux on my local server in the
end. I had nothing else to do tonight so I decided to give my ktorrent-problem another chance.
I have been suspecting that it might have been a problem for ktorrent that its main storing place was of FAT32.
And we all know that Fat has its limits.
So what did I do? :
I deleted .kde/share/apps/ktorrent first,so that I even could start ktorrent again (yes it was that bad) .
I dont understand why ktorrent remembered my configuration (storing place,ports etc. ),but the torrents
that I had been trying do download was gone,so in the end it just made it easier for me.
I changed the place of storage to an ext3 or 4 not sure,but now I am gonna check how it works when I start downloading.

If nobody thinks this information is interesting then just tell me,and I will end posting about this.

-H

OK! The solution for me was the FAT partition. Why the problem started after an update is still unknown for me,and I probably will never know. The slow ktorrent is however gone,and I got my very nice torrent-client back.

So if anyone that read this has anything to do with the updates,Fedora or ktorrent: Never change a winning team.


Thanks for reading.

-H

Decreasing priority of stalled torrents, should not result in KT hanging, I need to investigate this.

So to conclude, you have a lot of torrents, and the QM when it runs freezes things.

I'm going to simulate this.

Sam wrote:I was also playing with things QM related over the weekend, and I did notice that whenever the QM runs there was alot of disk activity. Could it be that the QM is writing the Order number to disk for each change of order? (e.g. If i move torrent with order number 1,001 to the top of the queue, then QM is doing 1,000+ disk writes as it moves entry 1,001 to place 1, then writes again as it moves the old place 1 to place 2, then writes again as it moves the old place 2 to place 3, etc.???)

It could be something like that, something which does not matter when you have 20 torrents, but does when you have a 1000.

Try latest svn, this should have been fixed a couple of days ago.

Sam wrote:bummer, latest svn doesn't really fix the hang time for the queue manager handling 1,000+ torrents. Without resorting to a stop watch, I'll guess it cut it by 10-20%? The original ~90 second hang is now ~78 seconds, but I have a java app running in the background now that I didn't then, so maybe a bit less? (Or maybe no change at all, not really sure what I was running then.)

Messing around in the queue, seemed to be pretty smooth after my last changes. I would be interesting if you could run ktorrent in valgrind (with callgrind as tool), that way I can have a better understanding of what is going on.

Is there a post somewhere on how to run two copies of KT concurrently that use different configs and data dirs? Testing the scripts on my fully loaded KT is somewhat a pain... Oh, and a post on the proper flags for make install, so make creates a private object (e.g. doesn't overwrite /usr/bin/ktorrent)? (And anything else I might need?) Point me in the right direction and I'll do the wiki write up(s).

The easiest way to do this, is to use another user

I also think that it is not Queue Manager's fault (at least not directly), because I experience lags with only a few torrents running and it is strictly correlated with download speed. If I set max. down speed to 100kB/s or less - no lag, between 100 to 300 kB/s lag gradually increases and eventually rendering interface unusable (though downloads continue at that speed, I just cannot change anything).

I cannot test at speeds > 300 kB/s, my Internet connection does not allow that. It is worth noting that the NFS throughput is much higher (around 2MB/s), so it is not a network problem. I think on NFS the problem is more evident, because protocol overhead for opening/closing/syncing files is higher than on USB-drive for example.

About interface unresponsiveness, it might be helpful that besides open/close calls in strace logs there are also many long futex calls. My guess that UI tries to be "too synchronous" with working threads (I didn't really look into code yet, it's just a guess) and when they experience delays UI starts lagging (surprisingly it does not affect worker threads that much, though I just might not be able to see it because my Internet connection is rather slow).

PS I tried to run ktorrent in valgrind, but it is less helpful than strace, because on my machine it cannot reach fullspeed under valgrind (and even if it could've I don't think it helped because it looks like thread-synchronization problem to me, which is hardly seen in callgrind. I may be wrong of course:))

PPS I'll try to update to latest 3.x version next week.