mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Low upload speed when seeding #573
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#573
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @vlad-i-mir on GitHub (Jun 6, 2013).
The uploading speed is very, very low. I have never seen the upload more than 2-3 or 5 MB/s when in the same time on the same MAC with the same internet channel, for example, transmission can seed 15-17 MB/s for easy.
@sledgehammer999 commented on GitHub (Jun 6, 2013):
Can you use the english language for the screenshot? Tools->Options...->Behavior->Lagnuage
Also, do you use the same torrent in qbittorrent and transmission or different torrents?
@vlad-i-mir commented on GitHub (Jun 6, 2013):
In future I will use only english language. Sorry, I didn't paid attention for this thing. If it necessary to renew screens, please let me know.
Every test I used the same torrents, in the same time, on the same Mac, with the same settings.
Process was the next:
Did it again for a few times (morning/evening, Monday or Sunday etc.)
Did it also with utorrent and vuze. The same.
@sledgehammer999 commented on GitHub (Jun 6, 2013):
Do it for qbt because I don't know what each column means.
So only qbittorrent showed the problem?
@vlad-i-mir commented on GitHub (Jun 6, 2013):
Yes, you are right, only qBittorrent showed low level of upload speed. Screen:
@Seeker2 commented on GitHub (Jun 11, 2013):
In my testing with a 5 mbit/sec upload line, qBT v3.0.8, v3.0.9, and v3.1.0 experimental for windows won't use more than ~9 upload slots even when I have it set to 50. :(
Others at the forum mentioned having the same problem: http://qbforums.shiki.hu/index.php?topic=1839.0
On fast connections, this causes poor seeding ( http://qbforums.shiki.hu/index.php?topic=1877.0 ) and probably even reduces download speed because qBT can't Tit-For-Tat with >10 other peers at once like other BitTorrent clients can.
Does qBitTorrent have a hidden global max upload slots that's hard-coded to 10 or less?
@sledgehammer999 commented on GitHub (Jun 11, 2013):
As far as I can tell from the code no. This is a libtorrent bug. I'll try to report it tomorrow.
@vlad-i-mir commented on GitHub (Jun 15, 2013):
Any news about the issue?
@pbondoer commented on GitHub (Jun 22, 2013):
Is this going to get fixed or do I have to switch my torrent client again? :(
@sledgehammer999 commented on GitHub (Jun 23, 2013):
Upstream bug report: https://code.google.com/p/libtorrent/issues/detail?id=488
@vlad-i-mir commented on GitHub (Jun 23, 2013):
I switched to another torrent-client till the problem will solved. Waiting for new release. Also always open for questions, requests, tests etc.
@sledgehammer999 commented on GitHub (Jun 23, 2013):
@vlad-i-mir since I can't reproduce the problem, your testing/reporting will be very helpful. I am really glad that you still offer to help. Thank you.
@Gelmir commented on GitHub (Jun 23, 2013):
Might test seed_choking_algorithm = fastest_upload
From lt manual:
@Seeker2 commented on GitHub (Jun 24, 2013):
Here's a screenshot of the bug in action:
http://www.imagebam.com/image/036fe6261948228
Sufficient peers are present that I should at least exceed 10 upload slots.
Seeding only, uTP is disabled, half open slots is set to 8, no trackers used, UPnP, DHT, LPD, and PEX all disabled (passive seeding).
I "primed" the torrent on the same port via another BT client that had no problems connecting to >60 peers. That program was shut down while qBitTorrent was running.
@sledgehammer999 commented on GitHub (Jun 25, 2013):
Could you test the new build from here: http://qbforums.shiki.hu/index.php?topic=1747.msg6981#msg6981
It is build with the latest libtorrent which contains fixes about upload. If this still doesn't fix the problem I will upload a new one which will use fastest_upload as seed_choking_algorithm.
@Seeker2 commented on GitHub (Jun 26, 2013):
The newer build...didn't do any better:
http://www.imagebam.com/image/6b792d262312581
@sledgehammer999 commented on GitHub (Jun 27, 2013):
I changed the seeding algorithm to fastest upload and increased the connections per second to 20.
Please use the build from this post: http://qbforums.shiki.hu/index.php?topic=1747.msg7018#msg7018
27/06/2013
@Belove0 commented on GitHub (Jun 27, 2013):
Maybe I'm missing something, but the final screenshot in English clearly shows an upload speed of 639.2 KiB/s and a maximum speed setting of 650 KiB/s. The two speeds are nearly the same, so I would be happy :). It would be bad policy to use more connections than required to achieve that speed, even if settings were configured to allow it, as that would:
(1) generate more protocol overhead and be less efficient, and
(2) With more connections, take longer to get whole pieces to other clients, thereby slowing down redistribution of the torrent throughout the swarm as a whole, ultimately effecting everyone detrimentally, with no benefit to the seeder in question.
It sounds like you all and Arvind (upstream) have this well in hand, and all I can offer are untested theories :)
But I would like to introduce general bandiwdth management policy considerations, if it hasn't been considered that the maximum upload and download rate can play a role, especially if not all connections are using uTorrent protocol (which attempts to automatically backs off when the network is overloaded). The rule of thumb with all Torrents clients is to set your max download and upload to 20% below your tested capacity. However, unless uploading is prioritized carefully (Automatically lowering download speeds so they don't interfere with the upload limits set), upload speeds will suffer significantly due to protocol overhead requirements on the uplink (IP overhead, TCP acknowledgments and resends, Bittorrent negotiations, DHT traffic).
Even if you are not downloading anything, you still have the overhead which is more or less some percentage of your downloading speed (TCP ACKs/resends, BT negotiation) plus DHT traffic.
If downloading on a connection with more download than upload bandwidth, no matter what, your maximum possible upload rate will go down. Reducing the number of download connections and increasing the number of upload connections will help with the TCP competition (which is basically won based on number of connections). If downloading reducing the download max rate will increase the upload max rate possible. In my experience, the "20% rule" can be disregarded and experimentation with the rates and connection limits can allow you to maximize your connection if desired.
uTorrent calculates traffic different than most other clients (last I checked) in that it has long had the option, and now I think it may be default, to calculate all protocol overhead and include it in it's upload and download speeds reported; knowing the real bandwidth usage this way also allows the lower level functions to make better choices, even when you disable the option to display those numbers in the interface/graphs (since the numbers are higher, they're encouraging; albeit possibly confusing to see an upload rate when you are only downloading).
In this specific reported case, I know there are no downloads in progress ,however there are a couple optoins I think should always be enabled to allow qBT to best manage bandwidth, and aren't enabled:
(1) Set a global maximum download rate.
(2) Enable bandwidth management (uTP)
(3) Apply rate limit to transport overhead (if this results in rates lower than you want, just increase your global rate limit)
Without (1) it is very difficult for qBT/libtorrent to balance upload/download
Without (2) you are tossing out a feature that will prioritize other traffic on your network a little more (which you may or may not prefer) but will also allow qBT to balance upload/download. If your uplink gets saturated, downloads will suffer because protocol overhead is delayed. Also vice-versa, although if you are on a typical home connection with much faster download than upload, you are less likely to see uploads suffer due to overhead on your downlink.
Without (3) the real overhead traffic cannot be considered in bandwidth management. (I'm convinced uTorrent does not count ALL protocol overhead, so it may be challenging to determine this accurately insofar as the overhead is at low levels (TCP and IP) and assumptions and guesses may be made rather than sniffing low level traffic to count things like resends done automatically by the system) ).
In theory with just the uTP bandwidth management enabled and if all clients also have it enabled, a client might be able to management traffic on its own with no limits set at all... but I wouldn't count on it. uTP itself is hampered by the way the UDP and TCP protocols work and can only be so successful. There is buffering on the OS, as well as on routers that make it difficult to accurately guess what the network congestion is like (which uTP tries to do, and is much better than nothing).
A second recommendation (besides using the above settings), if it doesn't already exist, is to have a configurable option for prioritizing seeding or downloading (radio button choice possibly) or even a third option to balance the two (in which case if there is unlimited demand on both upload and download links, make sure no less than half of the bandwidth is used for payload on either link, so the slowest link will never use more than 1/2 of its capacity for overhead regardless of impact on the other link's transport speed.
@Seeker2 commented on GitHub (Jun 28, 2013):
"the final screenshot in English clearly shows an upload speed of 639.2 KiB/s and a maximum speed setting of 650 KiB/s."
639.2 KiB/s only at the moment of that snapshot. The upload speed was jumping around 400-650 KiB/sec.
"Please use the build from this post: http://qbforums.shiki.hu/index.php?topic=1747.msg7018#msg7018"
Ok, I'm now using that version.
"I changed the seeding algorithm to fastest upload and increased the connections per second to 20."
I am seeing a high peer churn rate, maybe due to this?
The other BT client (with same port+settings and blocking some peer ips on the torrent) can connect to 10-30 more peers than qBitTorrent, cause unknown.
Low upload speed is partially due to differing peers, but qBT still refuses to use >9 upload slots:
http://www.imagebam.com/image/aa7aa6262722191
@sledgehammer999 commented on GitHub (Jun 28, 2013):
Maybe the other client is allowed to use uTP connections? You seem to have disabled utp on yours. Can you try with utp on?
@Seeker2 commented on GitHub (Jun 28, 2013):
"Maybe the other client is allowed to use uTP connections?"
The other BT client certainly had uTP disabled as well.
Probably just luck, not every peer may be retrying my ip:port at any given minute.
"You seem to have disabled utp on yours. Can you try with utp on?"
When I enabled uTP in qBT and forwarded UDP on my router to my computer's ip+port, I got a few more connections as expected.
I also enabled PEX in qBT, so even more connections arrived.
But is qBT supposed to upload to uTP peers in preference over regular TCP-using peers?
http://www.imagebam.com/image/4fee7c262764571
Is there supposed to be an Uploaded column? Or do I need to enable that somehow? It seems a shame to show Downloaded 0 B for everything while seeding and not see Uploaded.
@sledgehammer999 commented on GitHub (Jun 28, 2013):
I have observed that most clients prefer to connect via utp. Back when qbt was using libtorrent 0.15.x(no utp), torrents which hadn't big swarms were slow to download but when switching to a utp client speed was picking up.
However, you still were connected to only ~10 peers, although you have set more than 10 upload slots, right?
Yeap there is. It is just a bug for when using 3.1.x on top of a 3.0.x conf file, which used one less column.(the 'flags' was introduced recently.) I'll try to fix it but for the moment the only solution is to delete your qbittorrent.ini file. (all settings will be lost).
@Seeker2 commented on GitHub (Jun 29, 2013):
"However, you still were connected to only ~10 peers, although you have set more than 10 upload slots, right?"
I was connected to about 60 peers, but uploading to fewer than 10 of them. So <10 upload slots. The remaining ~10 peers up to the 70 total shown in the picture represented half-open connections (and uTP equivalent) to peers that were probably not going to connect.
It's my guess that the majority of connected peers remain idle, as the upload slots are very poor about cycling through all the peers. The Optimistic Unchoke upload slot does try different peers, but it's slow and cannot reach more than a handful before many disconnect.
"for the moment the only solution is to delete your qbittorrent.ini file. (all settings will be lost)."
Eliminating/replacing my settings may help if I goofed something up somewhere.
I'll test more on this either late today or sometime tomorrow.
@sledgehammer999 commented on GitHub (Jun 29, 2013):
I pushed a fix. Also you can manually delete this entry in qbittorrent.ini for the time being: Peers\PeerListState=
As for the other, I'll nudge arvid to take a look here again and maybe suggest things.
@sledgehammer999 commented on GitHub (Jul 1, 2013):
@Seeker2 can you try this build: https://mega.co.nz/#!9ERyGaoL!aDFeb0PxRxoTL-kOEZp8WA88dx8oUIILfFE9q0uQf1M ?
It uses infinite unchoke slots (session_settings::unchoke_slots_limit = -1;). Patch included in the installer.
EDIT: I think this patch slows down browsing a lot, when downloading torrents.
@Seeker2 commented on GitHub (Jul 2, 2013):
With the 6/27 build from a couple days earlier, over a 1 hour period, I took 5 screenshots:
http://www.imagebam.com/image/9b8a66263190929
http://www.imagebam.com/image/fe72d6263190933
http://www.imagebam.com/image/bfe8d8263190938
http://www.imagebam.com/image/0642f2263190941
http://www.imagebam.com/image/a69073263190946
A few peers mostly monopolized my upload, others got little, and by the 5th screenshot over half had disconnected.
I couldn't use that link the your later version, web browser gets this:
"Your browser does not allow data to be written. Please make sure you use default browser settings."
I tried it on another computer with a later version of Firefox, same error message.
Internet Explorer gets "done but error messages in the page".
The http://builds.shiki.hu/ links you've used before work fine though.
@sledgehammer999 commented on GitHub (Jul 2, 2013):
@Seeker2 I am sorry. It seems that mega.co.nz doesn't work well with Firefox 22. I had to download Firefox 17 from portableapps to be able to download the file. I'll drop using mega in the future.
Anyway, here is that build: http://builds.shiki.hu/temp/qbittorrent_3.1.0alpha01072013+patches_setup.exe
Pay attention also if it degrades browsing.
Also in git master I restored the seeding_algorithm to the default one. It seems that fastest_upload is too biased towards fast peers as you suggest.
@Seeker2 commented on GitHub (Jul 3, 2013):
Ok, the build from here:
http://builds.shiki.hu/qbittorrent_3.1.0alpha30062013_setup.exe
...seemed to still have the global upload slot limit of ~8-9.
But this one:
http://builds.shiki.hu/qbittorrent_3.1.0alpha03072013_setup.exe
does not!
However...I am guessing this is the reason it works:
And that causes weird behavior -- I don't see an optimistic unchoke upload slot, sometimes it decides to upload to almost every connected peer, but other times it uploads to at most the same number of peers as I set upload slots to.
If I reduce upload slots max, active upload slots are not choked...they continue uploading until they disconnect.
If I use TCP View to break them, they won't be uploading after reconnect unless active upload slots are below upload slot max.
There does not appear to be any upload rotation between peers outside of disconnections.
My total upload speed also seems spread more evenly between peers than before, though this may only be the case because most peers can download at 5-30 KiB/sec from me but some might not do >80KiB/sec:
http://www.imagebam.com/image/6bf36b263578803
I'm guessing this is "as designed/as intended" as the changes you did to "force" more upload slots to be used (infinite unchoke slots via session_settings::unchoke_slots_limit = -1;) was a bit of a test rather than what you intend to use in the non-beta release.
@sledgehammer999 commented on GitHub (Jul 3, 2013):
Are you sure you didn't confuse the builds you were refering to? Because it doesn't make sense.
This build: http://builds.shiki.hu/temp/qbittorrent_3.1.0alpha01072013+patches_setup.exe
Has round_robin as seeding algorithm and infinite unchoke slots.
This build: http://builds.shiki.hu/qbittorrent_3.1.0alpha03072013_setup.exe
Has round_robin as seeding algorithm and default unchoke slots.
This build: http://builds.shiki.hu/qbittorrent_3.1.0alpha30062013_setup.exe
I can't remember exactly but it only has fastest_upload as seeding algorithm.
Please check again with the first build I linked(unlimited unchoke slots) to confirm.
Also this build: http://builds.shiki.hu/temp/qbittorrent_3.1.0alpha04072013+statistics_setup.exe
Is a vanilla git master build(round_robin+default unchoke) BUT I have enabled statistics logging in libtorrent. When you run it a logfile will be created in "C:\Program Files\qBittorrent\session_stats" (or equivalent).
Please email it to me (sledgehammer_999 at qbittorrent.org) so I can attach it to the upstream bug. This will help the libtorrent author debug the problem and maybe suggest solutions.
@sledgehammer999 commented on GitHub (Jul 3, 2013):
Also state how many upload slots have you set in the settings.
@Seeker2 commented on GitHub (Jul 4, 2013):
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
sledgehammer_999 at qbittorrent.org
(I replaced the at with a @ symbol with no spaces.)
Well, I tried...
Any chance this is caused by the same reason why I can't post at the forums?
"Anyway, here is that build: http://builds.shiki.hu/temp/qbittorrent_3.1.0alpha01072013+patches_setup.exe
Pay attention also if it degrades browsing."
I forgot to mention that I didn't see any degrading of web browsing, but I am not testing downloading...I'm only testing seeding!
"Are you sure you didn't confuse the builds you were refering to? Because it doesn't make sense."
You're quite correct about me getting build versions mixed up...
"Please check again with the first build I linked(unlimited unchoke slots) to confirm."
Yes it does allow far greater than 9 upload slots at once:
http://www.imagebam.com/image/6bf36b263789142
At ~530 MB ram used by qBT, I get this weird error message:
04/07/2013 00:50:44 - Reason: Torrent file () error: Not enough space
04/07/2013 00:50:44 - An I/O error occurred, 'Torrent' paused.
04/07/2013 00:50:44 - Reason: Torrent file () error: Not enough space
04/07/2013 00:50:44 - An I/O error occurred, 'Torrent' paused.
(Torrent is not actually the name of the torrent in question.)
As I tried to open the Options as qBT reached the ~530 MB ram usage limit, I got this crash:
http://www.imagebam.com/image/21bf72263789153
This seems to be the result of me setting qBT's write/read cache to 1000 MB size and 600 seconds duration coupled with my relatively high upload speed of ~600 KB/sec.
The crash did not seem to occur with the cache set to <400 MB.
On:
qbittorrent_3.1.0alpha04072013+statistics_setup.exe
Upload slots were changed from 90 down to 5 to test choking/unchoking mechanisms.
qBT continuted to upload to far more than 5 peers even 10+ minutes after reducing upload slots to 5:
http://www.imagebam.com/image/a28a4a263789161
I did not see the Optimistic Unchoke Upload Slot (O flag) used at all.
@sledgehammer999 commented on GitHub (Jul 4, 2013):
I am sorry. Typo. It's sledgehammer999 (without an underscore). Please send again.
This is serious. Please send email at the admin(shiki) shiki.biomernok at gmail.com
Ignore the RAM issue for the moment. When we fix the upload we can talk about that(remember to open new bug for that. I'll probably forget it)
Not respecting max upload slots is a problem. I'll check with the libtorrent author.
@Seeker2 commented on GitHub (Jul 6, 2013):
I have sent the email and didn't receive an error message this time, so hopefully you got it.
I'll deal with the crashing RAM issue later then.
@sledgehammer999 commented on GitHub (Jul 6, 2013):
Yes, I have got it and send it to upstream. Check the bug linked above. I am waiting a reply from the libtorrent author.
@sledgehammer999 commented on GitHub (Jul 10, 2013):
Here is a new build. When you right-click a torrent file and select "rename..." a special dialog will come up with some info. Please copy paste them here after you upload to many peers that exceed the set "max upload slots" setting. This build also uses unlimited unchoke slots. These are info that were requested from the libtorrent author in the bug.
http://builds.shiki.hu/temp/qbittorrent_3.1.0alpha_11072013+patches_setup.exe
@Seeker2 commented on GitHub (Jul 11, 2013):
In my testing, something got screwed up...
qBT now thinks I have 0% of the torrent and on a different drive than where I have the data located.
When I try to point qBT to the location where the data is stored, nothing seems to happen.
But...qBT is stuck in memory on exit after doing this.
Even if I could work around this problem, getting qBT to do a recheck over the whole torrent will take hours.
@sledgehammer999 commented on GitHub (Jul 11, 2013):
qbt probably didn't close cleanly in one of those tests. Unfortunately this causes the settings to not be saved correctly. It is on my list to fix for 3.1.0.
What you can do and maybe not lost any downloaded data is this:
Alternatively:
skip the data checking stage and start seeding immediately@Seeker2 commented on GitHub (Jul 12, 2013):
I definitely cannot use that first method, as that's exactly what I tried. When I set the correct location, qBT continued looking at the initial location and would get stuck in memory when I tried to close it.
The alternate method worked, fortunately...saves hours of force recheck.
I had a hard time doing the actual test, because after random amounts of time qBT would pause the torrent and start trying to do a complete recheck of all the data.
Does it do this if it's been informed of hash fails? Or is this the result of internal self-checks?
Execution Log gave no clues to the cause -- there was no message corresponding to these stop-and-recheck events.
Screenshots showing upload slot use tests:
http://www.imagebam.com/image/28806f265051719
http://www.imagebam.com/image/d9948c265051711
http://www.imagebam.com/image/5d870d265051715
...And crashes that occurred during these tests:
http://www.imagebam.com/image/d31539265051723
http://www.imagebam.com/image/68cf0c265051724
The crashes seemed to be from 2 different causes. Once was from opening Options menu at a bad moment, while the other was an "unassisted" crash on its own.
@sledgehammer999 commented on GitHub (Jul 12, 2013):
Libtorrent author asks if you are downloading from peers in the local network that's why the limits are exceeded. Are told him probably no. Was I correct?
About the crashes: If they happen with the regular builds, create a separate issue and we will try to troubleshoot them.
@Seeker2 commented on GitHub (Jul 12, 2013):
I start qBT, with both max connections and max upload slots per torrent set to 90. Outgoing half-open peer connection attempts may be about 10.
After I get >40 connected peers on the torrent I'm using for testing, I verify that almost all connected peers are being uploaded to.
Once they are, I lower upload slots to 20.
I also lower outgoing half-open peer connection attempts to only 1 to reduce churn.
(My expectations when connected peers are nearly in a steady state that upload slots should try to round-robin upload to as many peers as possible when seeding. Tit-For-Tat upload slot behavior may partially override this on downloading torrents to a degree, but even still the optimistic unchoke slot should roam arount to attempt to find better reciprocating peers.)
Over 10 minutes later, qBT is still uploading to considerably more than 20 peers as the screenshots show.
No local peers are needed or used to trigger this behavior.
Excess peers beyond my current upload slot limit are not being choked after an unchoke-choke cycle (which can be anywhere from about 30 seconds to 5 minutes) like they should be.
The optimistic unchoke upload slot is not being used under these conditions, probably because current upload slots exceeds max upload slot limit.
Newly arriving peers do not get an upload slot until most existing uploading peers disconnect.
I wanted to see if after a couple hours conditions would improve, but typically within 30 mins of start other bugs intervene to stop my testing.
@sledgehammer999 commented on GitHub (Jul 13, 2013):
Maybe you should consider subscribing to the bug and answering directly the questions of the libtorrent author. Because when I am the middleman it takes time to post back and forth your questions/answers between the 2 bugreports. Libtorrent bug 488
Also about the crash relating to memory ram. Maybe qbt somehow is hitting the 2GB memory limitation inherent on 32bit apps/OSes. Could you lower your cache to something more conservative? The same for the cache expiry.
EDIT: If you don't set max uploads to 90 and leave it to 20, do the connected peers still exceed this limit?
@Seeker2 commented on GitHub (Jul 13, 2013):
If that's the case, he could just email me or vice-versa.
The crash happens at ~530 MB ram used by qBT for v3.0.10.and later but doesn't happen till ~1600 MB ram used for v3.0.9.
I have lowered the cache and tested smaller values and shorter cache expiry values.
This crash doesn't happen below ~500 MB, so presumably up to ~400 MB cache size should be safe.
If I initially have qBT set to 20 upload slots per torrent and never raise that value, qBT does not seem to exceed the limit of 20.
@sledgehammer999 commented on GitHub (Jul 13, 2013):
I told him that. And I also commented this:
Is that correct?
This strongly indicates that may be a 2GB limitation problem. Does the system page pool reach close to 1GB or 2GB?
I don't think he'll do that. If you already have a gmail.com/youtube/google account you can already comment on that issue. No need for extra registration. Otherwise write here your email and I'll forward your request in the 488 bug.
@Seeker2 commented on GitHub (Jul 13, 2013):
"Is that correct?"
Yes, seems so.
The peers that exceed the limit are not choked and the only way to get back down to the limit is wait till random peers disconnect, which seems to happen semi-quickly due to peer connections being slightly unstable. I typically lose >20 peers within 5 minutes of reducing the upload slots well below the number of connected peers.
Rather than spam this thread more, I'll just email you about the off-topic issues.