@eyedeekay
+R4SAS
+RN
+RN_
+Xeha
+orignal
FreeRider
Irc2PGuest22478
Irc2PGuest48042
Onn4l7h
Onn4|7h
T3s|4_
aargh3
acetone_
anon4
eyedeekay_bnc
not_bob_afk
profetikla
shiver_1
u5657
weko_
x74a6
dr|z3d
one to keep an eye on: IfNTLPbQ~2CjcPMJRkMBb1YQpLldGZUe9fIuIrYmxZU=
dr|z3d
orignal: you don't have a sliding scale for RI expiry based on the number the router has in its netdb?
dr|z3d
~15K known routers on this one, and I doubt it's unique: IfNTLPbQ~2CjcPMJRkMBb1YQpLldGZUe9fIuIrYmxZU=
orignal
ofc I do
orignal
15K is a floodfill I guess
weko
15K - normal count for floodfill
dr|z3d
might be normal in i2pd land.
dr|z3d
that's a lot of RIs to be handling, floodfills don't need to hang onto them for very long.
dr|z3d
you could try a more granular approach, orignal
orignal
always 1 hour at floodfill
dr|z3d
slower b/w tier routers get expired sooner. 1 hour expiry? dang, and 15K. that's hmm.. interesting.
orignal
same as on Java routers
orignal
propose better algorithm
orignal
yes 1 hour expiry
dr|z3d
if K,L,M or unreachable and known peers > 2000, reduce expiry by 50%. or something.
orignal
we should change it together with zzz
orignal
but yes it's good idea to expire shiity routers earlier
dr|z3d
I don't even bother writing shitty routers to disk. saves on disk churn.
zzz
that's up to you, no need to coordinate with me
orignal
I think we should
orignal
for floodfills
zzz
our strategy is very different from yours already
orignal
I think 1 hour expiration is the same
zzz
yes, can't make it much lower, because that's how fast routers publish
dr|z3d
1 hour expiry and 15K routers seems a lot higher than I've seen, but maybe i2pd routers are getting more ff traffic.
orignal
but expire shitting routers in 30 minutes makes sense
orignal
bad luck fr them
zzz
not if you're ff, you can't, if they published to you
zzz
if you got it from an inbound connectoin, thats different
dr|z3d
if not current release version && K, L or M or unreachable, no transit tunnels for you! :)
dr|z3d
but yeah, 1h seems like the min expiry, so maybe just don't write the shit to disk, orignal, at least then when you restart the router the shit is gone for a moment or 2.
zzz
i got my own stuff I'm working on, don't bring me in to help on crazy drz ideas ))
dr|z3d
off you go then, zzz :P
dr|z3d
it seems that when you start to go higher than 4-5K known peers, the shit grows exponentially while everything else is linear. so 4K is a good cutoff.
dr|z3d
on non-floodfill routers I see around 2-2.5K at startup, given the crap isn't written to disk. plenty.
dr|z3d
and if you're not discriminating too much on what to build local tunnels with, that helps at startup.
dr|z3d
as a loose rule of thumb, P+X tier should be > L tier routers. that's what I'm working with.
dr|z3d
and unreachable no more than 20% of total netdb.
dr|z3d
(for non-ff)
weko
Some person reported about 24K transit tunnels
Xeha
26K was the max i've saw on mine
Xeha
or almost, 254.. something around that
Xeha
lots of tunnels, but not much traffic then
weko
It is spikes
weko
Main issue what it is spikes, not normal value
dr|z3d
add some offending router hashes to your blocklist, kiss goodbye to shitty tunnels. or don't.
dr|z3d
or block a couple of /24s in your firewall, failing that.
dr|z3d
reasonable transit tunnels on a fast router is about 6-8K. more than that, you're probably hosting crap for a tunnel spammer.
dr|z3d
fast router right now, ~3.4K tunnels, 7MB/s. that's a bit more "normal".
dr|z3d
the b/w is spiking at that rate looking at the graph, but transit tunnels aren't.
Xeha
its not an issue, dr|z3d
Xeha
its not really cpu intensive
dr|z3d
sure, from a sole router perspective it's not much of an issue, Xeha, but from the network's perspective it's definitely an issue.
Xeha
if i'd block them, others would see higher load.
dr|z3d
sure, you'd just be shunting the problem elsewhere without a global network-wide ban. that's already happening, i2pd is bearing the brunt of the spam.