Enhancing Anacrolix/Torrent Speed: Tips for Matching Libtorrent Performance #953
Replies: 3 comments 5 replies
-
Hey @anacrolix, were able to get a chance to take a look into it? Thanks |
Beta Was this translation helpful? Give feedback.
-
Your best bet is to check the status output (from WriteStatus) when a client doesn't seem to be downloading quickly. It will tell you the state of the connections to the client.
It looks correct. PEX/DHT won't matter if you're adding peers on a heartbeat.
Per above the status output is most helpful. If you can create a way for me to reproduce this I would be able to assist much more. I would try with less peers (say 20), I suspect anacrolix/torrent isn't optimal when it comes to waiting for connections that have less data. Ah I see that's reflected in your testing. I would suspect connection churn to be the main issue. |
Beta Was this translation helpful? Give feedback.
-
@anacrolix during torrenting of parcel called Note: I started capturing the status when peer1 (master node) has 100% pieces. The peer1 usually completes fast because, as I said earlier:
After download, the peer1 just does a copy operation to full-status-combined-peer1.txt |
Beta Was this translation helpful? Give feedback.
-
Hi @anacrolix,
Overview
We are currently replacing old libtorrent library (1.1.5) with anacrolix/torrent (v1.56.0) in order to distribute our internal binary (lets call it parcel) of size around 13 GB among all the nodes(peers) in our cluster.
Architecture:
Cluster Architecture
Within our cluster, we have master node and its workers nodes that report the state of the cluster to the master. The master generates the .torrent file. The torrent file is a trackerless torrent file. The master somewhat acts as a tracker and provides information to each peer about what other peers to communicate to during torrenting.
Torrent Architecture
For Torrenting, we have the architecture (this is independent of the torrent client library that is used) as follows:
AddPeers()
from the torrent client. ThisAddPeers()
API call happens after every Heartbeat response from master to worker peer.Stats with libtorrent 1.1.5:
With libtorrent 1.1.5 which is quiet old, we see that it distributes the parcels in 50 node cluster in ~5 mins. This result remains same regardless of the cluster size, whether we use 5 node cluster or 50 node cluster.
Client configs
The client config for libtorrent is as follows
Stats with anacrolix/torrent:
But when we switch the torrent client library to anacrolix/torrent, then in a 50 node cluster, the parcel distributes completes in 26 mins and in a 5 node cluster it completes in ~7 mins.
Client configs
The client config for anacrolix/torrent is as follows:
For both the libraries DHT is disabled. Since for historical reasons with libtorrent, we have seen unknown peers anncouncing themselves and joing the network causing multiple customer escalations.
Analysis from logs using different libraries:
With Libtorrent:
From the logs of worker node, the rate of progress( i.e
totalDownloaded
field) is very quick. As a result a 13.2 GB parcel download completes very quickly via torrent. Also due to this the fallback never occurs ie. (HTTP download from web seed)With Anacrolix/torrent:
The logs from the same peer, shows very slow progress rate (i.e
PiecesCompleted
) for the same parcel size And eventually it fallbacks to HTTP download from the web seed.Eventually every peer fallbacks on the webseed to download the parcel from it. This overloads the webseed.
I have enabled debug level logs on anacrolix/torrent but I don't see any thing incriminating.
Questions
Can you please help me with the following questions:
TIA!
Beta Was this translation helpful? Give feedback.
All reactions