However, loading up too many items into your download queue at once will slow all of them down. Everything looks terrific, and you want to grab it all. Sometimes downloading torrents can feel like being a kid in a candy shop. If you have the option, plug your computer directly into your modem or router with an ethernet cable to get the fasted possible download speed. We’ve all become used to the convenience of Wi-Fi, but a wireless connection can be dramatically slower than a direct or wired ethernet connection. Download requests must have IMMEDIATE_PRIORITY_INTERVAL_SECS, since they already sent in batch and it is not wise to delay them.Īfter these tweaks trunk version of Transmission was able to download at full speed of 5 MB/s.Download via a direct, wired Internet connection It is not good and results in download speed drops. Download requests were delayed for HIGH_PRIORITY_INTERVAL_SECS seconds in protocolSendRequest() function. R5980 also introduced download speed drop. It prevents too often requests flood and higher speed (after r7234 of course). In my tests good results were achieved when calculating requests for 1 second ahead. Currently the number of requests is calculated for 30 (!) seconds ahead and they are sent in one batch. In r6101 ratePulse() code was changed and requests flood cases started to happen too often. uTorrent can download from uTorrent at 5MB/s speed under the same conditions.
But download speed is not good enough (~2 Mb/s). Rejected requests are deleted from peerAskedFor list and download do not stop. In 100MBit LAN Transmission downloads from uTorrent for 3-5 seconds and then stops for 240 seconds.Īfter r7234, Transmission properly reports that it supports fast extensions and uTorrent sends reject messages for requests that it can not handle at this moment. After that timeout, peerAskedFor list is cleared and download starts again for some time until uTorrent will be flooded with requests again. The download just stops for SENT_REQUEST_TTL_SECS (240 seconds). They remain in peerAskedFor list and Transmission can not send new download requests. Since Transmission did not report that it support fast extensions, uTorrent do not send BT_REJECT message and silently drops these requests. At some point the number of requests becomes to high and uTorrent can not handle them. Here is scenario for Transmission before r7234:ĭuring download, Transmission calculates the number of download requests based on download speed in ratePulse() function. However, Transmission had some fast extensions code for long time (for example BT_REJECT message). The problem occurs at least with uTorrent client as seeder when download speed is relatively high.īefore r7234, Transmission did not report that it supports fast extensions to other peers. After 2 days of building and testing I can explain all :)
0 kommentar(er)
