0.9.33 Snark traffic "vanishes"

Issues and ideas about I2PSnark
Post Reply
jogger
Posts: 45
Joined: 19 Feb 2018 09:00

0.9.33 Snark traffic "vanishes"

Post by jogger »

I am putting it here because new topics are disabled in "I2PSnark".

Snark does not work in 0.9.33 as in previous versions. Since I have only metrics, no hard facts I am not yet opening a Trac ticket.

I am always seeding several large torrents with 5 - 15 leechers and have noticed that since 0.9.33 leechers take much longer to finish. My outbound traffic is unchanged, throughput always at least 5 kbps on average per active connection.

Before 0.9.33 the fastest leecher had finished by the time I had seeded twice the amount of the original data volume. This ratio is down to around 3 or worse for many torrents. I have an unfinished 6GB torrent online since 4 weeks with 6 leechers, where I have seeded 345% with the fastest leecher standing at 77%. Before the fastest leecher would easily complete this one within one week.

I have got unfinished torrents where I alone have distributed much more data than all leechers show combined, not taking into account that leechers exchange additional data. This difference is so significant, it can not be attributed to leechers that went offline at some point in time.

All taken together this leads to the conclusion that Snark sends out traffic that somehow gets lost before properly stored at the receiving end. Any advice?
Qubes
Posts: 12
Joined: 23 Feb 2018 15:52

Re: 0.9.33 Snark traffic "vanishes"

Post by Qubes »

There are a few editions of independent Snark floating on Postman and Bobthebuilder. Te
jogger
Posts: 45
Joined: 19 Feb 2018 09:00

Re: 0.9.33 Snark traffic "vanishes"

Post by jogger »

I have watched this quite some time now. Traffic does not exactly vanish, but with 0.9.33 most of the time only part of the leechers do actually connect. So less traffic per torrent and Snark hands out the same pieces again and again because not all bitfields are known with the effects described above.

I suspect some resource shortage. I have first disabled open trackers, because this feature overlaps with DHT, and actually get more connections, torrents run faster.

Then I noticed NTCP connections were maxing out all the time. I raised i2np.ntcp.maxConnections=1234 and again noticed a speed improvement. Not sure about connection numbers though. Any advice on other tunables is welcome.
jogger
Posts: 45
Joined: 19 Feb 2018 09:00

SOLVED! 0.9.33 Snark traffic "vanishes"

Post by jogger »

SOLVED! Now I am running with:
i2np.ntcp.maxConnections=3333
i2np.udp.maxConnections=111

and open trackers off.

More peers connected, 20-30% better throughput and significantly less CPU at the same time.
echelon
Posts: 205
Joined: 10 Feb 2018 13:36

Re: 0.9.33 Snark traffic "vanishes"

Post by echelon »

Hi

Hm, I am not sure what your issues really are.
DHT does not really overlap with OpenTrackers, just a enhancement. At least it should not stop active traffic or transfers. Enabling OpenTrackers should help, except you do have a huge list of active torrents and do run into limits of the OpenTrackers, in which you are blocked for some time on them.
The amount of connections is another topic. Sure, if you do set your bandwidth limit high, the amount of active connection is limited. This is because of security reasons, e.g. usually each linux system has mostly a number of max 1024 open files, which renders >1000 connections not helpful at all.
But if you do run in connectivity issues, it may hinder your experience a bit, as clients who wants to reach you, may not be able to reach you in first tryout.

Just a big contra: I2Psnark has only 6 IN tunnels, and those are built on the active connections, so it should work flawless even with limits in connection reached.
About the amount of connections:
- UDP is preferred in I2P
- UDP is faster
- UDP uses more CPU
- deo not overload your SOHO router/system with too much open connections.

Overall it look slike your CPU is not really a fast one or you do have a huge load of active torrents in one single I2PSnark instance.
Yes, removing limits will give a better performance overall, as I2P does not need to check for these limits and activly remove connections, but it is hard to believe thats the only reason here.

echelon
Qubes
Posts: 12
Joined: 23 Feb 2018 15:52

Re: 0.9.33 Snark traffic "vanishes"

Post by Qubes »

I use a gaming machine with Qubes OS and for i2p I had to switch to a fast small OS (Fedora Security Labs at this writing) because of the demands on the CPU and the system in general. So shut down whatever you can and there is no need to reseed everything!

There are also other torrent clients!
jogger
Posts: 45
Joined: 19 Feb 2018 09:00

Re: 0.9.33 Snark traffic "vanishes"

Post by jogger »

I took into account echelons advice and have now removed all connection and bandwidth limits, except participating tunnels. I want to seed torrents fast. This is why I want as many peers connected as possible so Snark can determine the optimum pieces to distribute. Open trackers compete with peers for connections so I turned them off.

My current SoHo router was then overloaded with TCP connections (I get more than 60% TCP vs. UDP though), so I lowered the participating tunnels until I rarely got "high message delay" or delays when surfing the web.

By limiting only participating tunnels I do not block any snark connections any time. After 2 days I got more than 700 KBps average snark upload which is quite good. After all the number of connected peers (in relation to those postman lists) does not seem to be up to the level I had in releases before 0.9.33, so still I am seeding the same pieces again and again to different peers.
Qubes
Posts: 12
Joined: 23 Feb 2018 15:52

Re: 0.9.33 Snark traffic "vanishes"

Post by Qubes »

It helps if you reseed some zzz update that has "millions" of seeders. Check by the number of seeds.
jogger
Posts: 45
Joined: 19 Feb 2018 09:00

Re: 0.9.33 Snark traffic "vanishes"

Post by jogger »

Nice hint, helps with routers not yet integrated well.

In my case with 3 snark instances running in one JVM the number of connected peers per instance varies by more than a factor of two within a short time. Peers may be connected for hours to one or two instances and are at the same time unable to connect to the others.
Post Reply