Opened 7 years ago

Closed 18 months ago

#623 closed defect (no response)

I loose all participating clients - not getting participating

Reported by: me_squared Owned by:
Priority: major Milestone:
Component: router/general Version: 0.9.15
Keywords: Cc:
Parent Tickets: Sensitive: no

Description

My router is online 24/7, but after 1-3 days it loses all participating clients, the share ratio drops to 0,00. It says "Network: OK" and after a restart everything works fine for the next 1-3 days. My internet connection is pretty fast, so I think I2P is the problem.

Subtickets

#1397: High transport.sendProcessingTime and Message delayclosed
#1402: Router thinks it is firewalled even though it is notclosedzzz

Attachments (6)

i2p-lowparti-node3.png (99.5 KB) - added by rfree 5 years ago.
i2p-low-participate-okserver-small.png (218.7 KB) - added by rfree 5 years ago.
bug-i2p-0particip-a1.2.png (96.2 KB) - added by rfree 5 years ago.
bug-i2p-0particip-a1.png (96.2 KB) - added by rfree 5 years ago.
bug-i2p-0particip-b1.png (94.3 KB) - added by rfree 5 years ago.
bug-i2p-0particip-c1.png (90.3 KB) - added by rfree 5 years ago.

Download all attachments as: .zip

Change History (23)

comment:1 Changed 7 years ago by zzz

Need more info to investigate further. Is your IP changing? Are there any clues in the logs? Are you also running a high-bandwidth client such as i2psnark? What is your max bandwidth setting? This could just be normal network fluctuation.

comment:2 Changed 7 years ago by zzz

Resolution: no response
Status: newclosed

comment:3 Changed 5 years ago by rfree

Component: unspecifiedrouter/general
Priority: minormajor
Resolution: no response
Status: closedreopened
Summary: I loose all participating clientsI loose all participating clients - not getting participating
Version: 0.8.130.9.15

This is still happening.

EDIT: to be more exact, in my case the node is not getting participating traffic almost ever, for affected nodes from start to days of uptime and more they always have 0-1 participating, sometimes for a moment 2 or 3 participating peers.

Seen that on 2 routers.

1) 0.9.15-0 debian 7 amd64 java version "1.7.0_65" OpenJDK Runtime Environment (IcedTea? 2.5.1) (7u65-2.5.1-5~deb7u1) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
network status in i2p: "OK"
network: good (megabits down/up), ping 10-50 to popular pages in my country, to 200 to other
cpu,net load is low
i2p downloads and seed dozens of torrents, there is irc running, not much other activity

On graphs I see participating is always 0 or 1. Usually 0. Share ration 0.01

Uptime: 2 days Network: OK
Peers Active: 40 / 35X Fast: 40 High capacity: 4X
Integrated: 57X Known: 62X Bandwidth in/out
3 sec: 51 / 93 KBps
5 min: 70 / 120 KBps
Total: 71 / 198 KBps
Used: 15 GB / 44 GB
Tunnels
Exploratory: 9 Client: 73 Participating: 2 Share ratio: 0.01
Congestion Job lag: 0 Message delay: 233 ms Backlog: 0

2) very similar os, other also good network, same shared (0-1 usually) also after day(s) of uptime, network is also forwarded on firewall and shows as "OK"

See attached image, the one with light-blue background.

3) other debian, on possibly even better connection, running custom i2p backups (over ssh) connection generating quite high traffic - this works GOOD - share ration over 4.00

How ever, during <2 days of uptime it also had almost no participating tarffic - see attachement with the dark-green background.

Last edited 5 years ago by rfree (previous) (diff)

Changed 5 years ago by rfree

Attachment: i2p-lowparti-node3.png added

Changed 5 years ago by rfree

comment:4 Changed 5 years ago by rfree

In addition one of the nodes message delay is jumping… it is say 723 ms for some time, when I look after an hour it shows 30 ms, some hours later it shows high one again - with no clearly visible reason.

comment:5 Changed 5 years ago by zzz

The tunnel acceptance logic may reject tunnels for any of a dozen or more reasons. Most of them come down to either bandwidth levels compared to the configured bandwidth and participating share percentage, or to general internet connection, router, and computer load. Alternatively, it's the router's reachability due to firewall issues. Also, local traffic is always preferred over participating traffic.

This tunnel logic has been tuned over many years and works reliably. On the lower left of the console, it will tell you why it's rejecting tunnels (or at least why it rejected the last tunnel request, it will change over time).

You're averaging 198 KBps (1.6 Mbit/s) out and 71 KBps (560 Kbit/s) in over two days. That's a very high, and very unbalanced, traffic pattern due to your "seeding dozens of torrents".

Clearly, that traffic is sufficient to regularly exceed the limits for one or more of the checks in the tunnel acceptance code. As you rarely accept tunnels, your peers will learn that your acceptance rate is low, and will send you requests much less frequently.

I'm confident that if you raise your router bandwidth settings up and/or reduce your snark bandwidth sufficiently, and give it some time, you will accept more participating tunnels.

comment:6 Changed 5 years ago by rfree

bug-i2p-0particip-a1.png :

Was over 1000/1000 80% still usually 0, overall 0 to 4 participating peers.

Now new test:

bug-i2p-0particip-b1.png :

Applied changes based on your comment and http://echelon.i2p/i2p/I2P.high.load.txt

Most of them come down to either bandwidth levels compared to the configured bandwidth and
participating share percentage

yes, this test (bug-i2p-0particip-b1.png) has 600/600 with 90%

or to general internet connection, router, and computer load.

Tested if the network (LAN, gateway/router, internet connection) is the problem, by running various p2p programs like torrents.
Result is, in normal torrent: 5 MB/s down, 200 KB/s down (probably could be more down but don't have yet data to seed), and running regular torrent has no effects on i2p router bandwidh, so the network is not congested.

Computer load: IDLE usually 300-350% (out of 4 cores, out of 400%), never seen load spiking ever below 100%.
This is a good i5 CPU.

Alternatively, it's the router's reachability due to firewall issues.

Network "OK", ports are forwarded.

Also, local traffic is always preferred over participating traffic.

Seems to have bw to support participating.

I'm confident that if you raise your router bandwidth settings up and/or reduce your snark bandwidth sufficiently, and give it some time, you will accept more participating tunnels.

Increased files no 4096. Did not changed max connection limit. Rised wrapper's memory limit.

i2psnark torrents are 100 limit up, 15 peers uploader limit.

So then lowering the i2p snark did not really helped. There is almost no other local activity (small http server tunnels, xmpp clients etc).

What else can help? I will test with even lower i2psnark limits.

Changed 5 years ago by rfree

Attachment: bug-i2p-0particip-a1.2.png added

Changed 5 years ago by rfree

Attachment: bug-i2p-0particip-a1.png added

Changed 5 years ago by rfree

Attachment: bug-i2p-0particip-b1.png added

comment:7 Changed 5 years ago by rfree

I think the problem is Message delay: 439 ms. Sometimes it stays around 20, at times jumps to 500 and more.

During high value (like 200) I tested, and CPU is idle (over 1 core free, eg. 250%), ping to faster http servers is 20-50ms.

So this seems to not be network congestion, network lag, or cpu overload.

How to find out what causes this message delay?

Changed 5 years ago by rfree

Attachment: bug-i2p-0particip-c1.png added

comment:8 Changed 5 years ago by rfree

Lowered i2psnark to almost nothing (15 kbps), and still same 0-3 participatings, tested for over 12 hours.

bug-i2p-0particip-c1.png

So then, it seems the reason for this problem is not yet listed, maybe it's actual bug then?

comment:9 Changed 5 years ago by rfree

Status: reopenednew

comment:10 Changed 5 years ago by rfree

Add a subticket #1397.

comment:11 Changed 5 years ago by rfree

Debugging with zzz.

More info about this node:
UDP and TCP prots are different.
Should be forwarded on firewall/gateway (but we suspect now maybe there is a problem with this)
The external IP is not automatically detected, but manually set (to the external IP, this is correct IP).

<rfree> ok, so SSU caps=B and below, in Stats: caps are OR
<rfree> 5 days uptme
<dg> B is SSU testing
<rfree> btw Laptop mode is NOT active
<rfree> IPv6 is disabled

Address(es): .. NTCP: [host=…… shows the public IP of the node
SSU shows the same IP
both NTCP and SSU show correct tcp and udp port.

<zzz> How about in the UDP section? (look at the big arrows only, ignore the little arrows)
<rfree> in UDP, also around 20, timeout around 20 minutes, only 1 has little down arrow and that one has in out 0.00/0.00
<rfree> of big arrows, all are up
<rfree> so no inbound UDP traffic then

<zzz> I believe that SSU thinks you are firewalled, but because you have specified the IP, you are still publishing an NTCP address
<zzz> ok. WIth your settings, I don't think you will see 'firewalled' in the console, even though SSU thinks you are firewalled

<zzz> it's a bad sign that SSU thinks you are firewalled, but I don't know the reason

<rfree> zzz, other then that, is it possible to have some participating after half-day, with so high message delay as 100-600 ?
<eche|on> yes, rfree

<rfree> zzz, allright. So how to test if it works again, just restart i2p and look at ihost0? they should who my external IP? instantly after restart?
— <zzz> SSU concludes it cannot get inbound connections after "peer testing", so it publishes introducers, so you won't get any further inbound connections
(the ihost0= to 3 are showing some other IPs then mine)

comment:12 in reply to:  7 Changed 5 years ago by somewon

Replying to rfree:

I think the problem is Message delay: 439 ms. Sometimes it stays around 20, at times jumps to 500 and more.


My Message Delay is almost always at least that much (when I'm routing participating traffic, anyway) and I still have lots of Participating traffic.

When not participating (such as when the router has less than one day uptime), my Message Delay varies between 30-400ms. When participating well (such as >4days uptime), my Message Delay usually varies between 360ms-1000ms, but is usually around 750ms. At the extreme upper end of my Message Delay, I start getting the Console message "Rejecting Tunnels: High Message Delay," but that is very uncommon for me.

My bandwidth, platform and reachability are similar to yours. I never have trouble routing Participating Tunnels after 2 days of uptime or so - my Total average bandwidth usage is about half of my total I2P bandwidth limits, with most of that being participating traffic. My Share Ratio is typically around 20.

I suspect (as you do, in later comments) that it's some other issue that's the problem. But I figured I would reply here to provide some more data for future users who might be concerned about Message Delay and other problems.

Thanks for all of these great bug reports, BTW!

comment:13 Changed 5 years ago by rfree

Firewall was throughly tested on same ports on same computer (after stopping i2p of course),
more details in #1400

comment:14 Changed 5 years ago by rfree

Add a subticket #1402.

comment:15 Changed 5 years ago by str4d

Milestone: 0.9

comment:16 Changed 5 years ago by str4d

Possibly related: #1038

comment:17 Changed 18 months ago by Eche|on

Resolution: no response
Status: newclosed
Note: See TracTickets for help on using tickets.