I2P support forum

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.

Very interesting. Thanks for going to the trouble to write all this up.

Thanks for valuing my work. BiglBT is no such resource hog as people say, when run at i2p typical speeds of just a few 100 KB/s. Not recommended on Windoze at all. 600 MB RAM should be sufficient.

Just enable classic mode and deinstall all addons except i2p. If your download came with an embedded JRE, just delete and replace via "ln -s" with your favourite Java 9+.

In the startup script set max memory to 160. I use the following VM options for classic mode: "-XX:MaxDirectMemorySize=64m -XX:MaxMetaspaceSize=48m -XX:MaxGCPauseMillis=20 -Xss128k"

It even runs nicely on ARM32 and probably other platforms without a proper swt.jar shipped. Just install swt-gtk or so from your distro, clean out the swt folder and copy your swt.jar there as swt-unknown.jar. Skip SWT updates afterwards.

jogger wrote: ↑06 Dec 2018 09:22 Slows down fastest leechers most and forces them to stay up longer.
[…]
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.

That your forced socialism here does not meet with contradiction amazes me a little bit. But tell us why you want to punish those who obviously do everything right to encourage those who deliberately or unintentionally block the torrent.

Update: Postman now allows 20480 pieces, thus further helping to keep piece sizes small.