Jump to content

Upload speeds profile when torrent in status Checked n%


Recommended Posts

I save my downloads to a NAS (Maxtor Shared Storage). I had a forced quit (Windows XP) which obviously caused uTorrent (version 1.6.1) to start checking my partial downloads. These progress very very very slowly (seen as Checked in the Status field).

Uploads for other clients display a saw tooth pattern where the upload increases to a value of, say, 10Kb and then slowly decays to 0Kb over a minute. There is a short delay and then the upload speed rises again to 10Kb etc etc etc.

This occurs even if you are only seeding one torrent.

If you pause the torrent being checked, and update tracker then you will see the upload speed climb to your max upload rate and stay at that rate. As soon as you initiate checking the saw tooth pattern of uploads starts....

This is on a AMD 64 3200+ with AV switched off and no obvious background processes running. Okay the filestore is on a remote disk but that surely can't be making that much of a difference. Watching the Disk Statistics shows the hashing occuring at much less than 1 per second.

It would be nice for the hashing to be much faster, but better for the community for the upload to remain unaffected - is this a queuing problem?

I also notice that adding a new torrent when one is being checked results in that torrent being held (with no download) until the checking torrent has finished. Surely the new torrent doesn't need threading and coud be allowed to proceed or is torrent launching not multi-threaded?

Nice client otherwise!

(when my final torrent is checked, I will apply the 1.7 beta and see if the problem can be recreated with a deliberate force quit on an active download)


Link to comment
Share on other sites

ah, but the most severe effect is seen when hash checking. Normal operation across the network is perfectly okay.

I will leave it for you to judge the feature request priority of

a) disk I/O going multi-threaded

B) concurrent hash checking and regular upload performance

c) concurrent hash checking and adding new torrents



Link to comment
Share on other sites

Yeah, multi-threaded disk IO was something ludde was planning on doing before, and IMHO, if it helps with these kinds of problems, then it's definitely an important request.

Concurrent hash checking wouldn't really help matters, and the usual slowness in hash checking isn't a limitation in the single-threaded design, but a limitation of hardware (disk drive or CPU, usually).

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...