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

Fix minor typos

adrian5
2021-04-15 21:16:16 +00:00
parent e1e30a2235
commit 6c61105fdb
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Performance-Tuning.md
+3 -3
@@ -110,7 +110,7 @@ schedule2 = session_save, 1200, 43200, ((session.save))
### Peers and slots
`rTorrent` uses a different philosophy than most other torrent client.
`rTorrent` uses a different philosophy than most other torrent clients.
#### Definitions
@@ -127,7 +127,7 @@ The `min_peers` values are responsible for asking more peers during an announce
It all depends on the global connection speeds (`throttle.global_down.max_rate`, `throttle.global_up.max_rate`) and available RAM.
1. every upload slot should have got at least `5 KiB/s` speed left (it's not really problem anymore with nowdays fast connection). Taking the above example, in the worst case download slots have `29 KiB/s` (`8700/300`) and upload slots have `7.3 KiB/s` (`2200/300`). That means the number of the global download slot can be increased if we notice that we run out of it.
1. Every upload slot should have got at least `5 KiB/s` speed left (it's not really problem anymore with fast connections nowadays). Taking the above example, in the worst case download slots have `29 KiB/s` (`8700/300`) and upload slots have `7.3 KiB/s` (`2200/300`). That means the number of the global download slot can be increased if we notice that we run out of it.
2. `throttle.max_downloads` and `throttle.max_uploads` slots are `50` now. In the worst case this allows downloading and uploading `6` (`300/50`) torrents at the same time, but this usually not a problem for seeding.
@@ -178,7 +178,7 @@ Related settings:
`network.max_open_files` limits the maximum number of open files `rTorrent` can keep open. By default rTorrent uses variable sized `fd_set`'s depending on the process `sysconf(_SC_OPEN_MAX)` limit. See [Networking tweaks](#networking-tweaks) section how to adjust it system wide.
Large `fd_set`'s cause a performance penalty as they must be cleared each time the client polls the sockets. When using `select` or `epoll` (until `libcurl` is fixed) based polling use an open files limit that is reasonably low (_is it still the case???_). The widely used default of `1024` is enough for most users and `64` is minimum. Those with embeded devices or older platforms might need to set the limit much lower than the default.
Large `fd_set`'s cause a performance penalty as they must be cleared each time the client polls the sockets. When using `select` or `epoll` (until `libcurl` is fixed) based polling use an open files limit that is reasonably low (_is it still the case???_). The widely used default of `1024` is enough for most users and `64` is minimum. Those with embedded devices or older platforms might need to set the limit much lower than the default.
(Due to `libcurl`'s use of `fd_set` for polling, `rTorrent` cannot at the moment move to a pure `epoll` implementation. Currently the `epoll` code uses `select` based polling if, and only if, `libcurl` is active. All `non-libcurl` sockets are still in `epoll`, but `select` is used on the `libcurl` and the `epoll`-socket. (_is it still the case???_))