Peer refreshing

[farnoy]

Hi,

I found that long running torrents are getting a major drop off speed after, say 10 hours. I'm left with two connections and achieving a low speed. If I pause the job and instantly get it running again, it quickly finds another 44 connections and maxes out my connection (torrent is healthy). Is there an option for updating the tracker in intervals? How can I maintain the speed and accept new connections?

[tatsuhiro-t]

There is --bt-tracker-interval option. --bt-request-peer-speed-limit option may also help if you mind low speed.

[farnoy]

Thank you, I will try those options.

[farnoy]

Nope, It still dies after a few hours, connections go back to zero, and when I pause&continue, I have 145 shortly after.

I'm using these settings:

bt-request-peer-speed-limit=100K
bt-tracker-interval=1200

[tatsuhiro-t]

With DHT and tracker enabled, and assuming you are downloading torrent, not seeding, it is very strange that there is no connection. Could you grab aria2 log and check that tracker announce is made correctly?
Because this issue needs few hours to occur, log file gets too big. So you can enable logging after the connection becomes 0 using RPC command and wait for tracker announce (minimum 1200+ secs for your settings).
To enable logging via RPC, you can do it using aria2rpc:

doc/xmlrpc/aria2rpc changeGlobalOption -l /tmp/log.txt

[farnoy]

Ok, I will do that next time I encounter the problem, but what about log
level? Most of my current logs are errors about not supporting UDP protocol.

On 22 January 2013 13:40, Tatsuhiro Tsujikawa notifications@github.comwrote:

With DHT and tracker enabled, and assuming you are downloading torrent,
not seeding, it is very strange that there is no connection. Could you grab
aria2 log and check that tracker announce is made correctly?
Because this issue needs few hours to occur, log file gets too big. So you
can enable logging after the connection becomes 0 using RPC command and
wait for tracker announce (minimum 1200+ secs for your settings).
To enable logging via RPC, you can do it using aria2rpc:

doc/xmlrpc/aria2rpc changeGlobalOption -l /tmp/log.txt

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-12542690.

[tatsuhiro-t]

Thank you. The debug level log is very helpful for debugging.

[farnoy]

Sure, I will include debug information also.

On 22 January 2013 14:05, Tatsuhiro Tsujikawa notifications@github.comwrote:

Thank you. The debug level log is very helpful for debugging.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-12543417.

[farnoy]

Ok, this happened again, I've executed the command to save the log, I will wait at least 20 minutes and then post it here.

[farnoy]

Where should I send you the logs? There's 4M of them.

[farnoy]

Compressed logs are here, starting around 10.53am to around 11.20. I've paused&unpaused Darksiders2 around 11.18, and two minutes later it was going full speed. There may be some noise from the RPC, since I've checked the webui a few times.

[farnoy]

Full config:

continue
dir=/home/kuba/Downloads
file-allocation=falloc
max-connection-per-server=4
min-split-size=5M
enable-rpc
enable-dht
bt-save-metadata
rpc-save-upload-metadata
force-save
bt-seed-unverified
bt-max-peers=0
bt-request-peer-speed-limit=100K
bt-tracker-interval=1200
save-session=/home/kuba/.aria2/session
input-file=/home/kuba/.aria2/session
jobs=20000
max-concurrent-downloads=99999
log-level=debug
log=/home/kuba/aria2_log

[tatsuhiro-t]

Thank you for the log. From the log, aria2 corrected peers from DHT (trackers are all udp but aria2 does not support them) and its peer list was full (1024 peers), but for unknown reason, aria2 did not initiate connection to those peers. The code to initiate connection is src/ActivePeerConnectionCommand.cc but unfortunately it does not have meaningful log message at the moment.
I'll make a patch to add log message and post the link here.
Could you apply the patch and do the same procedure again?

[farnoy]

I would have to compile aria2 from git master and then run it the same way?

On 23 January 2013 16:25, Tatsuhiro Tsujikawa notifications@github.comwrote:

Thank you for the log. From the log, aria2 corrected peers from DHT
(trackers are all udp but aria2 does not support them) and its peer list
was full (1024 peers), but for unknown reason, aria2 did not initiate
connection to those peers. The code to initiate connection is
src/ActivePeerConnectionCommand.cc but unfortunately it does not have
meaningful log message at the moment.
I'll make a patch to add log message and post the link here.
Could you apply the patch and do the same procedure again?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-12600115.

[tatsuhiro-t]

The affected source file has not changed since last release (1.16.1), so you can apply the patch to 1.16.1 tar ball. It is a little bit easier to build from git.

[tatsuhiro-t]

Patch is here: http://sourceforge.net/p/aria2/patches/61/

[farnoy]

Ok, I've cloned the repo and applied the patch, building manpages fails but the binary is intact
[WARN] Unknown option: jobs=20000.
I'll find some big download and leave it for the night. Hopefully, it will happen again and I will post logs tomorrow.

[farnoy]

This time, the scenario was kind of different, because I've had two bigger jobs that were not downloading since I added them (maybe the traffic from other jobs caused them to lose tracker messages) and they stayed at zero progress for about 9 hours. Here are the last 500k lines from the log.

[tatsuhiro-t]

Thank you for the log. With your help, I found the bug which potentially causes this issue. It was fixed in 550ac8c.

[farnoy]

No problem, happy to help. I will pull the fix and see how that works, thanks for your time.

[farnoy]

It has been verified by me twice since my last reply, and it maintains speed after several hours, thank you.