Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1646 closed Bug (invalid)

verifying local data very slow on large torrents

Reported by: neurophyre Owned by: charles
Priority: Normal Milestone: None Set
Component: libtransmission Version: 1.42
Severity: Normal Keywords:


I'm running transmission 1.42 built from source on Debian etch on a 600MHz VIA C3 box (low power x86 CPU). This is a fairly slow processor, but there is a credible post from a member of RSA, Inc. benchmarking a 90MHz Pentium as being capable of hashing 2.1MB/sec (megabytes, not megabits) with SHA1:

I am running transmission-daemon and the web interface only, no GUI as the machine is headless.

I have an approximately 21GB torrent which I've been working on for a while due to crashes in 1.41b4, and every time I restart it the 'verifying local data' stage takes a very long time while using nearly 100% CPU. I upgraded from an old version of Transmission + Clutch which had the "Have" vs "Verified" issue, with having downloaded a lot of data and not verified very much. I'm not sure if that's an issue here. Regardless, watching the web interface number of GB verified creep upwards during "Verifying local data," it may take 1-2 minutes to verify 0.01GB of data. Something is wrong with that as the CPU should be capable of hashing much more data per unit time with SHA1. Also, the disk is constantly thrashed during this process.

Please let me know how I can assist in debugging this issue.

Change History (4)

comment:1 Changed 13 years ago by charles

  • Component changed from Daemon to libtransmission

r7559 may improve this some. Could you try building r7559 or higher from the nightly tarball?

comment:2 Changed 13 years ago by neurophyre

I built 7652 and it didn't seem that much faster, although a number of other bugs are fixed.

comment:3 Changed 13 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

I've just done a comparison test between Deluge, KTorrent, and Transmission to see how it compares to the other clients. I compared a 4.1 GiB iso file that I seed.

Verify time for 4.1 GiB with Transmission 1.50 beta 1: 1 minute, 16 seconds
Verify time for 4.1 GiB with Deluge 1.0.7:             1 minute, 17 seconds
Verify time for 4.1 GiB with KTorrent 3.1.5:           1 minute, 28 seconds

If your disk is constantly thrashing, then the bottleneck is probably in disk I/O. Regardless, this isn't a Transmission bug.

comment:4 Changed 13 years ago by neurophyre

It may just be the hardware. The VIA C3 is a very poky processor, and I think it was improved to some degree by the changes in the latest nightly, just not to my guesstimate of the theoretical max. Thanks for looking into it.

Note: See TracTickets for help on using tickets.