Download speed

[anonymous]

When i start download torrent (size around 4GB) speed is 3MB/s or more (use CPU 5-10%), on gateway i see speed around +-30Mbits.

After few minutes torrent speed goes down to 300kB/s, 200kB/s... 1-5kB/s (CPU 50-60%), but on gateway i still see speed around 30-40Mbits. No failed blocks. Seeder told me, he is still sending out 30-40Mbits (3-4MB/s), but i download only 1-5kB/s from him.

OS: FreeBSD 5.4 SMP (rTorrent in jail) COMP: 2 x 2.8Ghz XEON 2GB RAM

Tried rTorrent 0.4.5 / libTorrent 0.8.5 and rTorrent 0.5.1 / libTorrent 0.9.1

[rakshasa]

Are you using ReiserFS?

[rakshasa]

Or any other FS that can't handle files larger than 4GB due to bugs or similar.

[SYB]

I also have the same problem. File system is ext2, the torrent size is about 9 GB, but it contains 350MB large files. 0.4.5/0.8.5 OS: Vectorlinux 5.1.

[Beam]

No i dont use ReiserFS, i use UFS. Same problem i got with 700MB files, i downloaded 700MB file, no faild blocks and uploader told me, he has uploaded to me 5GB.

[anonymous]

Same here. I haven't contacted any seeders to get the exact numbers of what they've been uploading to me but on several occasions I noticed the bandwidth reading of rtorrent is way off when compared with ntop running on my gateway yet there are no failed pieces. Running rtorrent/0.4.5 libtorrent/0.8.5 on debian sid.

[anonymous]

same here, got rtorrent/0.4.5 libtorrent/0.8.5 on FreeBSD 6.1

my actual speed show in rtorrent is 439.8 KB/s when my other FreeBSD box who acting as a router/firewall is showing me a bandwith of 792.823 KB/s.

and right now the only computer who running is my file server with the rtorrent... so all the bandwith came and go to that computer

same for the upload.... rtorrent show me: 64.8 KB/s and I got 93.438 KB/s from my router.

really not good for people who have a bandwith limit with their ISP

[Bruno]

same for the upload.... rtorrent show me: 64.8 KB/s and I got 93.438 KB/s from my router.

Well, I'm no expert in these kinds of calculations, but with an MTU of 1500 bytes and 40 bytes min size for a TCP (ACK) packet, about 3% of your download rate is just ACKs upstream. That might at least explain the upstream difference.

[Beam]

But i got differences like 1-2Mb/s in rtorrent and 30-40Mb/s on router.. Only for download, upload is OK i think.

[nospam1@local.se]

I also have this problem, but for me rtorrent also starts lagging like hell, making it almost unusable.

For example, if I download in 11mb/sec it says something like 5-6mb/sec during the first minutes or so, after that increasing CPU usage (from around 10-20% to 80-90%) and according to rtorrent dropping the downloadspeed by ALOT (iptraf does not agree tho, speed is the same as before), keystrokes takes a random 1 - 10 sec for rtorrent to process (every keystroke). This makes the client totally unusable during fast downloads.

[anonymous]

Same thing here with 0.8.5/0.4.5 on NetBSD with UFS. The speed displayed by rtorrent is always only about 60-90% of the actual incoming data (it's not just a display issue, rtorrent seems to throw the rest away). The busier rtorrent is (doing hash checks for example) the less of the incoming data it uses.

This is a really bad thing...

[rakshasa]

There is propably two different issues here, rtorrent not taking protocol overhead into account when calculating the rate, and something else.

I'll see what I can find, and we'll see if the next release fixes some of these issues. Though it seems everyone is using older versions...

[anonymous]

It isn't just protocol ovehead. We're talking about a 50-75% dataloss is most cases. I've been watching the speed of the torrent and the increasing downloaded size (That rtorrent reports, the xxx / yyy mb info of a torrent, and the speed rtorrent reports is the same as the actual size increment of the file. ie, the rtorrent reports the actual data being downloaded and put into files). But, the datastream I get from other peers are (for 1 single torrent) is often 50-75% higher than the actual data being downloaded. Somehow rtorrent is requesting data from peers, and getting it, but then just discarding 50-75% of it.. This is with libtorrent 0.9.3 and rtorrent 0.5.3 running Gentoo Linux 2.6.17-no2 (no-sources) on a 100mbit connection.

The other problem is that rtorrent lags like crazy under load, making every single keystroke take 1-10 seconds, making it unusable. Also, the CPU goes up when this happens, often around 60-70%, but sometimes as high as 90% (never 100%). I've got a 3500+ AMD64 with 1GB ram.

[anonymous]

I forgot to mention: upload speed seems to be correct tho.

[anonymous]

I've got a series of screenshots of rtorrent + system monitor + network monitor running at the same time (disk/ram/swap/cpu/network usage) as I download 3 torrents at 11mb/sec, that shows this problem with rtorrent, mail me at  nospam2@local.se if you're interested in seeing them, or in any other way get access to my box to try this yourself

[rakshasa]

Might be the bad handling of hash fails in previous releases, combined with skipped pieces not being included in the download rate.

Svn HEAD should have fixed both of these issues.

[anonymous]

Skipped pieces? So you mean rtorrent "skips" 50-75% of the data it requests? Because that's the numbers I get.

[rakshasa]

It doesn't, and there's more to protocol overhead than just how much piece data you are receiving. Most of the reports here are too vague for me to debug anything.

[anonymous]

Under heavy load rtorrent does indeed skip 50-75% of the data that gets sent to it, don't ask me to explain how, but I do have proof for it. As I said earlier, mail me for a collection of screenshots.

[anonymous]

concerning the high differences in speed you're mentioning.. is it possible you forgot to account the fact that rtorrent measures the speeds in bytes like (K/M/G) bytes per second.

where as your router/gateway might be measuring it in bits like (k/m/g) bits per second?

[anonymous]

No, I'm talking KiB and MiB here, but the problem does seem to be fixed in the svm version, it still freezes for a couple of seconds when under heavy load (not the computer, just rtorrent) and download speed drops to 0kb/sec during that time, but it does go back up to max again when it "unfreezes", so problem is kinda solved :)

[demian]

I too experienced this issue with versions up to 0.9.3/0.5.3. (Upload speed never seemed to be affected, though.) With the update to 0.10/0.6 this seems to have disappeared. I only installed it earlier today so I can't say for sure (cause the behaviour of rtorrent displaying only 40-60% of the real incoming traffic didn't appear all the time.)

Might be worth for everyone who experienced this bug to upgrade to the latest version and see if it persists.

[rakshasa]

The freezing is due to the use of sync to ensure data gets written. I tweaked the timeout so it should be slightly bettern in the current release. This will be fixed later, i hope.

[anonymous]

I'm the previous "Anonymous" poster. I've been using the latest release for a few days now at the problem seems to be fixed, exept for the freezing, I'll try out the current rel and report back when I've tested it under a 11mb/sec load :)

[radu.obada@gmail.com]

I experience the same "freezing" issue that some previous posters reported. My setup is as follows:

• libtorrent-0.10
• rtorrent-0.6.0
• operating system: Gentoo Linux, kernel: 2.6.16 (Gentoo patchset 2.6.16-r13);
• architecture: AMD64 (Intel Celeron D 2.53 MHz).

The problem is as follows: whenever my download speed goes above around 2 MiB/s, rtorrent starts hogging the CPU (I'm getting even 100% CPU usage), and the system comes to a grinding halt. I've tried various workarounds from changing the kernel, the network card and even the distribution, but nothing seems to work. Curiously enough, the upload is fine, I can go as high as my bandwidth holds. Please, please fix this problem, it is really annoying. Thanks ;-)

[anonymous]

radu: I've had the same report from several people using AMD64, which is unrelated to the bug in this ticket. Running rtorrent under valgrind's cachegrind or gprof might give an indication on where the problem accures.

[ian.abbott@lycos.com]

I've often seen rTorrent requesting and downloading the same piece from two different peers (at least that's what it looks like from the displayed information). Could that account for some of the missing data?

[rakshasa]

No.

I've found gprof hard to work with when profiling a library, but if I get a cachegrind report it would help.

[freak.shiva@gmail.comm]

bbyugbccjh

[freak.shiva@gmail.com]

== [

] ==