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. Please let my know if there's any other information I can provide, this is driving me NUTS.After 2 days of building and testing I can explain all :) And the fact it starts downloading OK initially leads me to think its a problem with deluge, not my network I cannot see any problems with my routing table / VPN connection, if I disconnect from the VPN the same problem occurs. At the moment I'm connected to 137 DHT nodes, 200 peers but have 'no incoming connections'. the whole process takes around 10 seconds and the download will progress no further, unless I restart the deamon, in which case the whole process starts again. My problem is: on adding a magnet link to the deamon my download starts, within a few seconds the download speed is ~200kBps, however after a few more seconds the download rate drops slowly to 0. The server and Deluge deamon are setup to connect to a VPN, I'm using deluge v1.3.6 on xubuntu 12.04.
I connet to this deamon from other PCs in my household to add torrents, which are downloaded to a file server. I'm setting up an ubuntu 12.04 server with the deluge deamon installed. This has been driving me mad for some days now.
0 kommentar(er)
