fujin/rtorrent
1
0
Fork 0
mirror of https://github.com/rakshasa/rtorrent.git synced 2026-10-05 13:49:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update min_peers* on Performance Tuning page

chros73
2018-05-13 18:41:09 +01:00
parent 65f04fcd7c
commit ff5de48db6
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Performance-Tuning.md
+2 -2
@@ -121,7 +121,7 @@ schedule2 = session_save, 1200, 43200, ((session.save))
- `throttle.max_peers.normal`, `throttle.max_peers.seed`: maximum number of peers to connect to per torrent while downloading or seeding. It can be seen (along with the connected peers) at the bottom left a torrent details page (using right arrow): `Peers: 43(0) Min/Max: 99/100`
- `throttle.min_peers.normal`, `throttle.min_peers.seed`: minimum number of peers to connect to per torrent while downloading or seeding. It can be seen (along with the connected peers) at the bottom left a torrent details page (using right arrow): `Peers: 43(0) Min/Max: 99/100`
The `min_peers` values are responsible for asking more peers during an announce request. When the client has less than `min_peers` connections for a download, it will attempt to request more from available trackers. 30 seconds after a request the client will attempt another if more than 10 new peer connections were gained or less than 3 requests have been performed. Else it will try the next tracker group in the list, but not other trackers in the same group. This behavior should give enough peers while minimizing the number of tracker requests, although it will use somewhat longer time than other more aggressive clients. In theory, if these values are `0` then rTorrent won't ask for new peers from the given tracker, peers can still connect though.
The `min_peers` values are responsible for asking more peers during an announce request. When the client has less than `min_peers - (peer_list_size / 2)` connections for a download and PEX doesn't result in connection for a download (if it's enabled at all), it will attempt to request more from available trackers using tracker `min interval`, otherwise using tracker `interval` (note: _this feature is [broken](https://github.com/rakshasa/libtorrent/pull/169) in `v0.9.6/0.13.6`_). 30 seconds after a request the client will attempt another if more than 10 new peer connections were gained or less than 3 requests have been performed. Else it will try the next tracker group in the list, but not other trackers in the same group. This behavior should give enough peers while minimizing the number of tracker requests, although it will use somewhat longer time than other more aggressive clients. If these values are `0` then rTorrent uses tracker `interval` all the time and won't ask for new peers from the given tracker, peers can still connect though (note: _does this part works at all?_).
#### Assigning the right values
@@ -133,7 +133,7 @@ It all depends on the global connection speeds (`throttle.global_down.max_rate`,
3. `max_peers` settings for downloading and seeding should be at least 2 times higher than the number of slots per torrent, hence the value of `100` for them.
4. `min_peers` settings are `99` for both uploading and downloading, meaning we always want to ask the tracker for new peers.
4. `min_peers` settings are `99` for both uploading and downloading, meaning we always want to ask the tracker for new peers more frequently, using tracker `min interval`.
#### Memory impact