@orignal
Irc2PGuest30010
Onn4l7h
Over
R4SAS
RN_
Strykar
Xeha
Yotsu
acetone_
b3t4f4c3__
duanin2
f00b4r_
hagen_
o3d3_
poriori
qend-irc2p
r00tobo
r00tobo[2]
rapidash
semantica
urist_
SlippyJoe_
when torrenting over i2pd , i see like an 7-10 times overhead in i2p traffic compared to the actual torrent payload . i understand some overhead is needed but this seems off
orignal
how about with Java?
onon_
What torrent client and what router are you using?
SlippyJoe_
i2pd version 2.58.0 (0.9.67) Boost version 1.90.0 OpenSSL 3.5.4 30 Sep 2025
SlippyJoe_
libtorrent-master
orignal
have you tried snark?
onon_
On both sides?
SlippyJoe_
i have not tried other routers nor other torrent clients
orignal
what is "libtorrent"?
SlippyJoe_
i compare libtorrent {up,down}load_payload_rate to what i see with with ` iftop -f "port $I2PORT" ` . with no transits allowed the traffic is low, as expected . with torrenting about 500K/s (up+down) it spikes to 5M/s
SlippyJoe_
libtorrent is github.com/arvidn/libtorrent
onon_
it's local buffer speet
onon_
speed
SlippyJoe_
what do you mean? am i looking at it in the wrong way?
SlippyJoe_
"On both sides?" - i'm working with regular postman torrents , i don't know of the otther ends
onon_
libtorrent transfers data to the i2pd buffer via a local socket. Then i2pd transmits this data through the i2p network and requests a new portion of data through the socket.
onon_
Your speed peaks are transfers from the local client to the local buffer via the local socket.
SlippyJoe_
onon_: i2pd runs on an other machine than the torrent client . the $I2PPORT variable (typo above) is the one i2pd-daemon bound to on public interface, so i assume this is real in/out traffic ?
orignal
you got an asnwer alerady
orignal
i2pd buffers data
onon_
How many tunnels does your i2pd use? Such bursts of traffic on the external interface can be observed when too many tunnels are configured.
onon_
Because tunnel tests happen simultaneously. And orignal doesn’t want to fix it.
orignal
no they are not
onon_
Another possible option is SSU2 retransmits. They are implemented very poorly and can produce such traffic peaks.
SlippyJoe_
thanks for answering
SlippyJoe_
not only peak bw is high, also the rates .f
SlippyJoe_
6.36Mb 10.1Mb 10.6Mb for roughly 1M/s torrent traffic
SlippyJoe_
in/out hops: 3 . sam in/out tunnels: 15
SlippyJoe_
i see a small number (about five) of IP are responsible for most of it...
SlippyJoe_
seems like a l o t of overhead to me
SlippyJoe_
would even warrant a wireshark session. any recommended filters ?
onon_
Another problem is that the input buffer in the canon i2psnark is too small. It cannot process the fast stream from i2pd, and some packets are simply dropped on the i2psnark client.
onon_
i2pd has a built-in mechanism for identifying such "slow" clients, but it does not always work well.
null912
is XD fast torrent client for i2pd? (never tried it)
onon_
I've also never tried XD so I can't say anything about it.
SlippyJoe_
null912: i tested once for half an hour. seemed unstable (few months ago)