Seeding a lot?
Posted: 06 Dec 2018 09:22
If you do, I suggest you take a look at BiglyBT.
First of all BiglyBT does away with Snarks pesty unsafe characters feature, which causes it often not to check its own torrents clean. There is one character substitution by default within BiglyBT, which I suggest you delete first. You can then freely move around torrents between Java versions, Mac and Linux.
You are then able to address two of the most annoying phenomenons for seeders that cause slower leechers to complete much later than possible :
- When your leechers go offline soon after they have completed, you may reduce the number of connections per torrent (I use 5 connections with 4 active transfers). Slows down fastest leechers most and forces them to stay up longer. Snark only has a global limit that failed in my testing.
- Also BiglyBT actively contacts leechers which helps with flaky connections on the other end and interruptions of any kind. Snark just sits there and waits for leechers to connect. If there is a crash on your side, BiglyBT is at full speed again a few minutes thereafter (writes state frequently to disk, trac ticket against Snark for this not honored); Snark may take hours for all torents to check and leechers to reconnect.
Both issues can further be improved by tuning the piece size when creating a torrent. I usually try to come as close as possible to 10240 pieces for torrents > 1 GB. (FYI: DifTracker and clearnet have no limits, Snark 32768 pieces, Postman 1024 files/10240 pieces). For torrents < 40 GB you can do this quite well with BiglyBT. This way overhead is introduced further slowing down fast leechers and piece size is reduced as much as possible which really helps unreliable leechers by drastically reducing the probability for them to fail on the up/download of each single piece.
Driving this to the max I created wrappers for py3CreateTorrent that calculate the optimum piece size down to 1 KB accuracy for Postman or Snark limits. Just as a precaution: First check the torrent clean in BiglyBT before uploading the .torrent elsewhere.
First of all BiglyBT does away with Snarks pesty unsafe characters feature, which causes it often not to check its own torrents clean. There is one character substitution by default within BiglyBT, which I suggest you delete first. You can then freely move around torrents between Java versions, Mac and Linux.
You are then able to address two of the most annoying phenomenons for seeders that cause slower leechers to complete much later than possible :
- When your leechers go offline soon after they have completed, you may reduce the number of connections per torrent (I use 5 connections with 4 active transfers). Slows down fastest leechers most and forces them to stay up longer. Snark only has a global limit that failed in my testing.
- Also BiglyBT actively contacts leechers which helps with flaky connections on the other end and interruptions of any kind. Snark just sits there and waits for leechers to connect. If there is a crash on your side, BiglyBT is at full speed again a few minutes thereafter (writes state frequently to disk, trac ticket against Snark for this not honored); Snark may take hours for all torents to check and leechers to reconnect.
Both issues can further be improved by tuning the piece size when creating a torrent. I usually try to come as close as possible to 10240 pieces for torrents > 1 GB. (FYI: DifTracker and clearnet have no limits, Snark 32768 pieces, Postman 1024 files/10240 pieces). For torrents < 40 GB you can do this quite well with BiglyBT. This way overhead is introduced further slowing down fast leechers and piece size is reduced as much as possible which really helps unreliable leechers by drastically reducing the probability for them to fail on the up/download of each single piece.
Driving this to the max I created wrappers for py3CreateTorrent that calculate the optimum piece size down to 1 KB accuracy for Postman or Snark limits. Just as a precaution: First check the torrent clean in BiglyBT before uploading the .torrent elsewhere.