I2P support forum

English is not my language so I took support of ChatGPT to paraphrase this whole article to convey as much as possible meaning to English speaking developers.



The Role of Piece Size in Resource Optimization for I2P Torrenting

When configuring torrents—particularly within privacy-focused ecosystems such as the I2P network—the selection of piece size plays a crucial role in determining resource consumption and distribution efficiency.

While this factor is often disregarded in clear-net torrenting due to the abundance of high bandwidth, its impact becomes significantly more pronounced in I2P’s constrained and latency-sensitive environment.



Understanding the Problem

Consider a scenario where a 25 GB torrent is divided into 2 MB pieces, resulting in approximately 12,781 individual pieces.

Empirical observations indicate that modifying the piece size—whether increasing it to 8 MB or reducing it to 64 KB—can lead to measurable differences in CPU and memory utilization by the torrent client.

In traditional clear-net environments, such disparities are largely mitigated by high-speed connectivity.

In fact, modern torrent clients such as qBittorrent and BiglyBT have begun experimenting with piece sizes as large as 256 MB in beta releases. These larger piece sizes minimize tracker and metadata overhead, which is beneficial when bandwidth is not a limiting factor.



Challenges in the I2P Context

However, this logic does not translate effectively to the I2P network.

Large piece sizes have been observed to cause several issues when torrents are either cross-seeded over I2P or created specifically for I2P users. Common problems include incomplete downloads, unstable peer connections, and inefficient swarm behavior—all of which degrade the torrenting experience.



Empirical Observations and Recommendations

Although a thorough code-level analysis of these behaviors is currently unavailable—owing in part to my own status as a non-developer—practical usage patterns reveal a consistent trend:

Torrents with smaller piece sizes perform more reliably and consume fewer system resources on the I2P network.

This trend is particularly evident in situations where bandwidth is limited and clients are not achieving peak I2P throughput.

Smaller pieces enable finer-grained data exchange, reduce memory overhead, and enhance peer-to-peer reliability, even at modest seeding speeds.

To illustrate:

Torrent A: 2 MB piece size → ~12,781 pieces

Torrent B: 512 KB piece size → ~52,121 pieces

Even if Torrent B is seeded at only 40 KB/s, it is more likely to maintain stable connections and reach a wider peer base—despite I2P’s well-known throughput limitations (as discussed in a previous post).



The .torrent File Size Trade-Off

Although it may seem counterintuitive, torrents with a greater number of smaller pieces (e.g., 512 KB in a 25 GB torrent) often perform better on I2P compared to those with fewer, larger pieces (e.g., 8 MB), even though this increases the size of the .torrent file and its associated metadata.

This performance improvement is rooted in the characteristics of I2P’s transmission model: the network is inherently slower, more latency-prone, and subject to frequent connection disruptions, all compounded by limited bandwidth. Within this environment, smaller piece sizes offer several advantages:

Faster and more reliable transfer of individual pieces

Lower risk of timeouts and incomplete downloads

Better utilization of peer connections by allowing parallel sharing of smaller segments

While the larger metadata overhead represents a one-time cost when loading the torrent, the long-term benefits—greater reliability, enhanced fault tolerance, and more efficient bandwidth usage—far outweigh this downside.



Implementation Limitations

As of May 2025, a significant constraint exists: both I2PSnark and the Postman tracker enforce a strict upper limit of 64,000 pieces per torrent. This is considerably lower than the thresholds supported by most clearnet torrent clients, which—based on user feedback, developer documentation, and AI-derived estimates—typically accommodate between 200,000 and 1,000,000 pieces, depending on the specific implementation.

For practical purposes, 200,000 pieces can be regarded as a conservative upper bound that is safely supported across the majority of modern torrent clients.



Conclusion

While definitive technical validation and a thorough code-level analysis of these behaviors is currently unavailable & remains elusive — owing in part to my own status as a non-developer, real-world usage suggests a clear pattern:

Smaller piece sizes enhance performance, stability, and resource efficiency when torrenting over the I2P network.

Creators and seeders targeting I2P are strongly encouraged to adopt smaller piece sizes during torrent creation. This seemingly minor configuration change can lead to:

Improved swarm connectivity

Reduced CPU and RAM usage

More consistent distribution among I2P peers

Despite the metadata overhead and the piece count limitations imposed by some I2P tools, the benefits of using smaller pieces are tangible and significant—especially in the unique constraints of the I2P ecosystem.

this is an interesting link shared by lgillis = http://zzz.i2p/topics/3436-removal-of-l ... an-tracker

I think this might be useful in trying to convey of what I am trying to convey. Even though the OP of this article had all together different use-case & meaning for his/her request

Thanks for the post.

I think you've overstated the benefits of small pieces and understated the costs. Also, clearnet torrents seem to be converging on the opposite philosophy.

20 years ago, snark did not handle large pieces and partial pieces well at all. Large pieces were not reliable. Today, all that is fixed. Partial pieces are not stored in memory, and are not lost on peer disconnect. Snark efficiently completes partial pieces and moves on. The piece size does not effect reliability except in one case: when you stop i2psnark, or restart your router, partial pieces are lost. So the bigger the pieces the more you lose. Maybe this is a small problem, but nobody's ever complained about it.

64K pieces is about a 1.3 MB torrent file. 200K would be 4 MB. That's all stored in-memory in snark, which is not great. You'd also have to convince postman to increase his limit.

Most clearnet torrents I see these days have 1024 pieces, and a non-power-of-two piece size. This results in a tiny 20 KB torrent file. Somebody has decided this is the best practice, to pick an optimal piece count, not piece size. Snark doesn't do this, it more-or-less finds the power-of-two piece size that results in less than 20K pieces. Perhaps I'll revisit that to bias it toward fewer (i.e. larger) pieces, which would bring it into closer alignment with current clearnet practices, but in opposition to your recommendations.

Let's see what others have to say.

Perhaps I'll revisit that to bias it toward fewer (i.e. larger) pieces, which would bring it into closer alignment with current clearnet practices, but in opposition to your recommendations.

Please do thank you.

I'd like to have the option to set the piece size when creating a torrent in i2psnark. If there's a way to do that, I haven't found it.

As far as the best piece size, I would say smaller is better. As slow as many I2P users are, a 4MB or 8MB piece takes a very long time to transfer, and it's a lot of data to lose if there's a connection problem or disconnect. It seems better to use the smallest piece size that will fit within whatever limits are required, to minimize that loss.