-
-
Notifications
You must be signed in to change notification settings - Fork 425
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Choke Manager slows uploads during downloads? #12
Comments
This requires some more detailed information on the upload/download speed (globally, per torrent, per peer), number of slots up/down (globally, per torrent), size of torrents and amount of memory. |
Closing this as there's not enough information provided. |
ghost
mentioned this issue
May 15, 2012
Open
This was referenced Sep 3, 2014
rakshasa
pushed a commit
that referenced
this issue
Aug 30, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have seen a definite pattern where all uploads run slowly until a torrent is 100% complete. Before the torrent is complete, the upload speeds are often (slightly) higher than the downloads, but they could clearly be uploading much faster. One of the clearest examples is on the "typical" Chinese HD sites with hundreds of peers and slow-downloading torrents (eg CHD, BHD, HDC): the download obviously can't go any faster but the uploads easily could. Then, as soon as the torrent finishes, I see an instant spike in upload speeds of 5-500%, depending on the peers remaining. The same thing happens even on small, fast-moving torrents from sites where most peers are local (eg BTN, SCC, GFT and many others)
My guess is that the choke manager is limiting upload speeds by giving priority to downloads until the torrent is 100% complete. This is normally a good algorithm but if downloads can't saturate the bandwidth then the uploads still seem to be throttled, wthich is just a waste. Even if this isn't the cause, do you have any theories or even better, a fix?
I'm using svn1272 but AFAIK none of this code has changed since before that.
The text was updated successfully, but these errors were encountered: