rtorrent ignores max_uloads_global and max_downloads_global

[IceD]

It ignores everything, I set in config and uses 20 for uploads and 80 for downloads.

[anonymous]

What did you set it to? What are your upload/download rate limits?

[anonymous]

Sorry, I have spent few hours reading source code (btw - code is great, thanks) I have found that params order matters. E.g. this:

upload_rate=100 download_rate=350 max_uploads_global=15 max_downloads_global=25

won't work while this:

max_uploads_global=15 max_downloads_global=25 upload_rate=100 download_rate=350

will. I'd suggest to document this issue (or fix it - I'll try to prepare patch if I'll find another 2-3 free hours).

PS. Also, please document proxy_address option which allows rtorrent to work through http proxy. I was mislead by http_proxy option (and thought that rtorrent can only use http proxy for tracker requests) and found this one only by accident.

PPS. Thanks for the best torrent client ever :)

[zipzap]

Setting a limit of concurrent torrent downloads is something I'm very interested in also, but this is not working for me.
I am running: rTorrent 0.8.4/0.12.4
from rpm compiled for Fedora10 and dl/installed via yum.
I have tried all sorts of combinations for these variables to put in various orders:
max_uploads_global=1
max_downloads_global=2
upload_rate = 10
download_rate = 15

It DOES seem like max_uploads_global does work, but you HAVE to define that variable before upload_rate, or it's ignored! (requiring a certain order for variables in the config seems like a BAD idea :)

The same does not seem to be true for max_downloads_global. I've tried it as the first variable and the last in the config file. I've tried it immediately before and after the download_rate variable and upload_rate variable.

With my practically non-existent C++ skills it would probably take me longer to even locate in the code than someone more familiar with it. Is this fixed in SVN yet?

[anonymous]

It's not fixed. The problem is that the slot limit is applied when the rate is set, so if you set the rate before the slot limit, changing the slot limit will be ignored (until you manually change the rate again anyway).

[anonymous]

And the problem still exists. Quite annoying, honestly.

[anonymous]

This would have taken me hours to figure out if I hadn't found the answer here. Shouldn't this have been fixed long ago?

[anonymous]

dont't work!

[anonymous]

First of all, max_*_global and max_*_div should not need to be changed on-the-fly. *_global sets upper limit of slots, and *_div defines minimum throttle rate per slots. Just set sane values for all of max_*_global and max_*_div at first, and forget about that. Then you can change throttle rate as you wish, and slots will be automatically adjusted.

For max_*_div, the manpage already says that those values are used "when the throttle is changed." I think adding some similar words to max_*_global (or merge them) is sufficient. Note that max_*_global is just upper limit of slots, not the direct value of slots. If the throttle rate and max_*_div gave lower value of slots, max_*_global have no effect by design.

Or in turn; on what purpose do you want to manipulate global slots on-the-fly? It doesn't affect usage of bandwidth nor sockets. It might change some disk access patterns, though, but I wonder you could control it meaningfully...