Opened 10 years ago

Last modified 5 years ago

#3581 reopened Bug

Upload speed to a single peer on a LAN capped at 1 MiB/sec?

Reported by: trunneml Owned by:
Priority: Low Milestone: None Set
Component: Daemon Version: 2.77
Severity: Minor Keywords:
Cc: chado@…

Description

We are using bittorrent in our university LAN to transfer large images. We tried Transmission-Daemon as the mainseeder. But there must be an hidden upload limit. We only get 1MiB/sec. The first 5 seconds the transfer rate shown in dstat is 20MegaByte per second. After that it goes down to ~1000k/sec. With ctorrent that we used before 20-40 Megabyte was normal.

I ask in the IRC-Channel if there should be this limit, the answer was no. So I think this is a bug.

settings.json:

  1 {
  2     "alt-speed-down": 50,
  3     "alt-speed-enabled": false,
  4     "alt-speed-time-begin": 540,
  5     "alt-speed-time-day": 127,
  6     "alt-speed-time-enabled": false,
  7     "alt-speed-time-end": 1020,
  8     "alt-speed-up": 50,
  9     "bind-address-ipv4": "0.0.0.0",
 10     "bind-address-ipv6": "::",
 11     "blocklist-enabled": false,
 12     "dht-enabled": false,
 13     "download-dir": "/srv/transmission/Downloads",
 14     "encryption": 0,
 15     "incomplete-dir": "/root/Downloads",
 16     "incomplete-dir-enabled": false,
 17     "lazy-bitfield-enabled": true,
 18     "lpd-enabled": false,
 19     "message-level": 2,
 20     "open-file-limit": 32,
 21     "peer-limit-global": 240,
 22     "peer-limit-per-torrent": 60,
 23     "peer-port": 51413,
 24     "peer-port-random-high": 65535,
 25     "peer-port-random-low": 49152,
 26     "peer-port-random-on-start": false,
 27     "peer-socket-tos": 0,
 28     "pex-enabled": true,
 29     "port-forwarding-enabled": false,
 30     "preallocation": 1, 31     "proxy": "",
 32     "proxy-auth-enabled": false,
 33     "proxy-auth-password": "",
 34     "proxy-auth-username": "",
 35     "proxy-enabled": false,
 36     "proxy-port": 80,
 37     "proxy-type": 0,
 38     "ratio-limit": 2.0000,
 39     "ratio-limit-enabled": false,
 40     "rename-partial-files": true,
 41     "rpc-authentication-required": false,
 42     "rpc-bind-address": "0.0.0.0",
 43     "rpc-enabled": true,
 44     "rpc-password": "{66a56f9a1540879fe9f9a76c4aeb7ff7ad185abajl2kO4kv",
 45     "rpc-port": 9091,
 46     "rpc-username": "",
 47     "rpc-whitelist": "127.0.0.1",
 48     "rpc-whitelist-enabled": true,
 49     "script-torrent-done-enabled": false,
 50     "script-torrent-done-filename": "",
 51     "speed-limit-down": 100,
 52     "speed-limit-down-enabled": false,
 53     "speed-limit-up": 100,
 54     "speed-limit-up-enabled": false,
 55     "start-added-torrents": true,
 56     "trash-original-torrent-files": false,
 57     "umask": 18,
 58     "upload-slots-per-torrent": 14
 59 }

PS: If this is not a bug, but a feature please tell me where in the code the limit is hidden. ;-)

Attachments (1)

fast-seeders.png (35.2 KB) - added by charles 10 years ago.

Download all attachments as: .zip

Change History (39)

comment:1 Changed 10 years ago by charles

I'm not sure how to go about testing this locally.

What I can tell you, though, is that it's easy to find instances of Transmission uploading at rates greater than what you describe -- for example see the attached screenshot, where I was downloading a linux ISO. two of the top three peers were Transmission, and they were uploading much faster than the speed limit you describe.

Changed 10 years ago by charles

comment:2 Changed 10 years ago by charles

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

comment:3 Changed 10 years ago by trunneml

Please don't tell me that I should try Transmission 1.98 ;-)

I found out that the upload speed increases up to 12 MB/sec it I start more peers in the network. So The problem I have is that, if I start Transmission on the mainseeder an start one peer. This peer gets 5 Seconds fullspeed and then 1MB/sec. Some time later this peer gets 12M/sec again and goes down to 1M/sec. And so one. Maybe there is a little hidden bug in the per peer bandwidth. Can you tell me please where in the code this part is handeled. I will look if I find something, that fixes my problem.

comment:4 Changed 10 years ago by trunneml

Here is the dstat output:

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 

  0   0  99   0   0   1|2640k    0 |  45k 1934k|   0     0 | 328   260 
  1   4  87   2   0   5|  11M    0 | 295k   14M|   0     0 |1291   619 
  2   4  87   2   0   5|  13M    0 | 320k   17M|   0     0 |1075   609 
  0   6  86   3   0   5|  17M    0 | 314k   19M|   0     0 |1291   786 
  1   4  85   2   0   7|  18M    0 | 329k   21M|   0     0 |1310   748 
  0   2  94   3   0   1|2576k    0 |  51k 2916k|   0     0 | 229   160 
  0   2  93   2   0   3|7488k    0 | 144k 7562k|   0     0 | 543   327 
  0   1  99   0   0   0| 688k    0 |  12k  715k|   0     0 | 157    82 
  0   1  99   0   0   0|2992k    0 |  53k 3137k|   0     0 | 217   141 
  0   1  99   0   0   0| 816k    0 |  15k  821k|   0     0 | 144   110 
  1   1  98   0   0   1|1712k    0 |  32k 2011k|   0     0 | 180   133 
  0   0 100   0   0   0| 464k    0 |  11k  453k|   0     0 | 103    85 
  0   1  99   0   0   0| 528k    0 |  13k  520k|   0     0 | 116    79 
  0   1  99   0   0   0| 592k    0 |  15k  514k|   0     0 | 168   107 
  0   0 100   0   0   0| 656k    0 |  14k  727k|   0     0 |  92    77 

comment:5 Changed 10 years ago by wereHamster

It would be interesting if you tried this patch: http://sprunge.us/LEIA. See #3563 what it tries to solve, maybe it's related to your problem. This fluctuation in speed could be a symptom of that bug.

comment:6 Changed 10 years ago by trunneml

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Sounds interesting. I will try the patch.

I reopen the bug, because I still think there is a bug.

comment:7 Changed 10 years ago by trunneml

@wereHamster: In the patch is a function call tr_time_msec(). This function is missing in 2.0.4:

./libtransmission.a(peer-mgr.o): In function `bandwidthPulse':
/home/trunneml/builds/transmission/src/transmission-2.04/libtransmission/peer-mgr.c:3134: undefined reference to `tr_time_msec'
/home/trunneml/builds/transmission/src/transmission-2.04/libtransmission/peer-mgr.c:3137: undefined reference to `tr_time_msec'
collect2: ld returned 1 exit status
make[1]: *** [blocklist-test] Fehler 1
make[1]: Leaving directory `/home/trunneml/builds/transmission/src/transmission-2.04/libtransmission'
make: *** [all-recursive] Fehler 1
Last edited 10 years ago by trunneml (previous) (diff)

comment:8 Changed 10 years ago by wereHamster

You can remove the calls to tr_time_msec() and the tr_dbg() call, it's only for debugging anyway.

comment:9 Changed 10 years ago by trunneml

Okay I tried it. But it didn't helps. Do you have some other patches that can help?

Is there away to see how long the event loop is blocked or any other way to check if this bug is a duplicate of #3563 or not?

comment:10 Changed 10 years ago by charles

Please don't tell me that I should try Transmission 1.98 ;-)

Not much chance of that....

What happens if you increase REQQ from 512 to 1024 or even 2048 in libtransmission/peer-msgs.c?

comment:11 follow-up: Changed 10 years ago by trunneml

Short question with or without the patch from wereHamster?

comment:12 in reply to: ↑ 11 Changed 10 years ago by charles

Replying to trunneml:

Short question with or without the patch from wereHamster?

Doesn't matter

comment:13 Changed 10 years ago by charles

  • Summary changed from Transmission slow Upload in LAN to Upload speed to a single peer on a LAN capped at 1 MiB/sec?

comment:14 Changed 10 years ago by trunneml

Okay I tried REQQ=2048 plus wereHamster patch with no change at all. 1 peer = 1MiB/sec and 3 peers = ~3MiB/sec.

comment:15 follow-up: Changed 10 years ago by wereHamster

Is that the speed how fast the seeder is uploading? The speed seems to be linear with the number of peers. So maybe the peers are limited to 1MiB/s download, or the network is limited to 10mbit ethernet somewhere between the peers.

comment:16 in reply to: ↑ 15 Changed 10 years ago by trunneml

Replying to wereHamster:

Is that the speed how fast the seeder is uploading? The speed seems to be linear with the number of peers. So maybe the peers are limited to 1MiB/s download, or the network is limited to 10mbit ethernet somewhere between the peers.

Yes, this is the upload speed and yes it is linear to the peer count and no all computers are on the same Cisco 1GBit switch.

I tried to switch the mainseeder from ctorrent to transmission (all other computers are still running ctorrent) and now the mainseeder doesn't upload as fast as before, but only 1 MiB/sec per peer.

We made no change in the Network if I start ctorrent on the mainseeder all is as fast as before. So the problem must be in transmission.

I will do some experiments with the libtransmission/peer-msgs.c and libtransmission/peer-mgr.c .

Do you know if there is as speed limit per peer or can you look if you find something like that? I don't know the code enough and my skills in C are bad.

Last edited 10 years ago by trunneml (previous) (diff)

comment:17 Changed 10 years ago by trunneml

I found some thing:

if I set BANDWIDTH_PERIOD_MSEC from 500 to 100, then each peer get not 1 MiB/sec it get 5MiB/sec.

So it has to do with BANDWIDTH_PERIOD_MSEC or the bandwithPulse function. There are TR_UP and TR_DOWN? What is set in this variables?

comment:18 follow-up: Changed 10 years ago by charles

It sounds like the server is only sending out blocks during bandwidth.c's phase one but not during phase two.[1] I wonder if the libevent callbacks that tell Transmission that a socket's ready for writing aren't being called?

trunneml, what version of libevent did you compile Transmission with? And was it compiled on the system where it's running, or was it cross-compiled?

[1] https://trac.transmissionbt.com/browser/trunk/libtransmission/bandwidth.c#L270

Last edited 10 years ago by charles (previous) (diff)

comment:19 follow-up: Changed 10 years ago by wereHamster

That's interesting. Because my patch basically kills phase one and does all IO through the libevent callbacks. And according to the OP it didn't cause any differences in the behavior.

comment:20 in reply to: ↑ 18 Changed 10 years ago by trunneml

Replying to charles:

It sounds like the server is only sending out blocks during bandwidth.c's phase one but not during phase two.[1] I wonder if the libevent callbacks that tell Transmission that a socket's ready for writing aren't being called?

trunneml, what version of libevent did you compile Transmission with? And was it compiled on the system where it's running, or was it cross-compiled?

[1] https://trac.transmissionbt.com/browser/trunk/libtransmission/bandwidth.c#L270

$ pacman -Ss libevent
core/libevent 1.4.14b-1 [Installiert]
    An event notification library

It was compiled on the system where it is running, so no crosscompiling.

Replying to wereHamser: No your patch didn't change anything. But in my last try I did not applied your patch. What I will do now.

By the way I still use the sourcecode 2.0.4 not the trunk.

comment:21 in reply to: ↑ 19 Changed 10 years ago by trunneml

Replying to wereHamster:

That's interesting. Because my patch basically kills phase one and does all IO through the libevent callbacks. And according to the OP it didn't cause any differences in the behavior.

I tried your patch and BANDWIDTH_PERIOD_MSEC=100. Same result as without your patch. Now 5MiB/sec per peer.

comment:22 Changed 10 years ago by trunneml

New Info: If only set BANDWIDTH_PERIOD_MSEC to 100 only in https://trac.transmissionbt.com/browser/tags/2.04/libtransmission/peer-mgr.c#L3134 nothing changes to the original behaviour.

But the following patch increases the performance 5 times:

diff -rupN transmission-2.04.org/libtransmission/peer-mgr.c transmission-2.04/libtransmission/peer-mgr.c
--- transmission-2.04.org/libtransmission/peer-mgr.c    2010-09-29 19:26:15.116094000 +0200
+++ transmission-2.04/libtransmission/peer-mgr.c        2010-09-29 21:26:49.000032000 +0200
@@ -3123,6 +3123,7 @@ pumpAllPeers( tr_peerMgr * mgr )
 static void
 bandwidthPulse( int foo UNUSED, short bar UNUSED, void * vmgr )
 {
+    const unsigned int start = tr_date();
     tr_torrent * tor;
     tr_peerMgr * mgr = vmgr;
     managerLock( mgr );
@@ -3156,8 +3157,7 @@ bandwidthPulse( int foo UNUSED, short ba
             tr_torrentStop( tor );
 
     reconnectPulse( 0, 0, mgr );
-
-    tr_timerAddMsec( mgr->bandwidthTimer, BANDWIDTH_PERIOD_MSEC );
+    tr_timerAddMsec( mgr->bandwidthTimer, BANDWIDTH_PERIOD_MSEC/5 );
     managerUnlock( mgr );
 }

As far as I understand bandwidthPulse is called every 500ms but I think the network doesn't send complete 500ms data only about 5ms or less and the rest of the time it waits. So where the hell can I setup how many data transmission should try to send each bandwidthPulse call?

comment:23 Changed 10 years ago by trunneml

Question: Is it possible that there is not enough data prepared for an transfer over the complete 500ms. So transmission sends all data out to the network and then waits for the next call of bandwidthPulse or something like that?

comment:24 Changed 10 years ago by trunneml

  • Version changed from 2.04 to 2.10+

Problem still exist in 2.10

comment:25 Changed 10 years ago by livings124

  • Version changed from 2.10+ to 2.04

comment:26 Changed 10 years ago by charles

(trunneml: we typically leave the version at the first version the issue was reported against.)

comment:27 follow-up: Changed 10 years ago by wereHamster

I'm not seeing a cap at 1MB/s, but I see that T is suboptimal when it comes to seeding at high speeds. On my 1 Gbit network I can only transfer at an average of 7-8 MB/s. And the speed fluctuates between 11MB/s and a few hundreds of kbyte/s. So there's definitely a problem, but no artificial cap at 1MB/s. This test was done between transmission-daemon on a linux box and Transmission.app on my macbook. Both versions were "2.11+ (git:aba4da9)", which should be the same as r11350.

comment:28 in reply to: ↑ 27 ; follow-up: Changed 10 years ago by trunneml

Replying to wereHamster:

I'm not seeing a cap at 1MB/s, but I see that T is suboptimal when it comes to seeding at high speeds. On my 1 Gbit network I can only transfer at an average of 7-8 MB/s. And the speed fluctuates between 11MB/s and a few hundreds of kbyte/s. So there's definitely a problem, but no artificial cap at 1MB/s. This test was done between transmission-daemon on a linux box and Transmission.app on my macbook. Both versions were "2.11+ (git:aba4da9)", which should be the same as r11350.

I had the similar effect. A short burst with 11MB/s and then only a a few hundreds kbyte/s (around 1M/s). My test was done between transmission-deamon and ctorrent. The speed increase linear with the peer count.

I think the cap results in how the "client" requests tokens. But ctorrent to ctorrent uses ~ 55MB/s normally.

wereHamser can you give me an tar.gz with your code to compile and test it on my linux system? Or can you tell me how to get this version out of your git and what must I do, that I can compile it like the normal tar.gz releases of transmission.

comment:29 in reply to: ↑ 28 Changed 10 years ago by wereHamster

Replying to trunneml:

I had the similar effect. A short burst with 11MB/s and then only a a few hundreds kbyte/s (around 1M/s). My test was done between transmission-deamon and ctorrent. The speed increase linear with the peer count.

Well, in my case the speed recovers again to 11MB/s, it does not stay a the low speed forever. It fluctuates between the low and high speed at about 0.2Hz. So I get an average of about 7-8MB/s.

wereHamser can you give me an tar.gz with your code to compile and test it on my linux system? Or can you tell me how to get this version out of your git and what must I do, that I can compile it like the normal tar.gz releases of transmission.

Get it yourself: http://github.com/wereHamster/transmission, all you need to do is run ./autogen.sh and then make

comment:30 Changed 10 years ago by jordan

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Is there any news on this ticket?

comment:31 Changed 10 years ago by jordan

  • Resolution set to worksforme
  • Status changed from reopened to closed

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. Thanks again!

comment:32 Changed 10 years ago by trunneml

Sorry I have exams and didn't found the time to test the latests version. Currently we are running an patched Version 2.04, were I increased the mainloop polling. I will try the latest Version this weekend.

If this problem still appears I will reopen this bug, again.

comment:33 Changed 8 years ago by C.H.A.D.o

  • Cc chado@… added
  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 2.04 to 2.77

Got the same bug on 2.52 and 2.77 OS: GNU/Linux, Debian 7 Client (peer) software: Enhanced CTorrent 3.03 Use iptraf to check upload speed

With BANDWIDTH_PERIOD_MSEC = 500, the speed near 524 kB/s With BANDWIDTH_PERIOD_MSEC = 100, near 2.7 MB/s With Enhanced CTorrent 3.03 as daemon, near 2.6 MB/s

If use 2 peer and BANDWIDTH_PERIOD_MSEC = 500, the upload speed is 1 MB/s (524 kB/s + 524 kB/s) 2 peer and BANDWIDTH_PERIOD_MSEC = 100, speed is 2.7 MB/s

comment:34 Changed 8 years ago by leo.unglaub

I have the same problem with transmission-gtk 2.77 (14031) on my Linux computer. No matter what i do i cannot upload more than 1 Mbit.

Greetings Leo

comment:35 Changed 7 years ago by jordan

Note, bug #5459 seems to be a duplicate of this and has a different suggestion on how to ameliorate the limits.

comment:36 Changed 7 years ago by jordan

Could someone hitting this limit give agz's suggestion in bug #5459 a try? I'm considering that approach and would like to get more real-world testing on it.

comment:37 Changed 6 years ago by gquintard

Hello there, This ticket is a bit old, but still valid.

I tested on a 1Gb link and I can only get 40-50 Mbits/s out of it. With the nload at the receiving end alternating with big surge for a few seconds, then no data for a few other seconds.

Using agz modification on #5459 I managed to get 250-260 Mbits/s, with a more constant bitrate. It's not optimal, but way better.

The version was transmission_2.84-0.2 from debian, on wheezy.

comment:38 Changed 5 years ago by snefi

Hello

I have same error. I cant upload higher than 11 MB/s but I have got 200 Mbps. Any update?

Note: See TracTickets for help on using tickets.