@eyedeekay
+R4SAS
+RN
+acetone
+orignal
+weko
Irc2PGuest33877
Irc2PGuest68850
Leopold
Onn4l7h
Onn4|7h
ProRu
T3s|4
anon1
eyedeekay_bnc
j6
not_bob_afk
polistern
profetikla
qend-irc2p
x74a6
zer0bitz
dr|z3d
ok, update re StormyCloud. we've fixed the bandwidth issue with the outproxy. tomorrow, more stuff.
dr|z3d
~85Mb/s achieved via a 0 hop from one datacenter to another (I think?) over a 0 hop connection.
Xeha
Megabits or MegaBytes?
orignal
I never understand what bakcup tunnels was for
dr|z3d
Xeha: Mb = Megabits, MB = Megabytes. :)
dr|z3d
orignal: it's a decorative feature :)
Xeha
aww, was hoping you made mistake and it would be actually MiB
dr|z3d
that would be something else :)
dr|z3d
anyways, the moral of the story to date is to make sure that your kernel supports queue discpline configuration, and definitely do not expect anything like acceptable performance from a kernel that doesn't, especially on an outproxy that coexists with a tor exit.
dr|z3d
I never realised a "noqueue" discipline was a thing before, I thought fifo was about as bad as it got. I was wrong.
zzz
dr|z3d, so what you were helping fix was the _tor_ exit performance?
dr|z3d
no, zzz. outproxy performance was poor.
dr|z3d
as a side effect, exit performance may also be improved.
zzz
so they actually have something up and running?
dr|z3d
I suspected the exit traffic was saturating the connection and bufferbloat was at play.
dr|z3d
still in the testing phase.
zzz
sure, but I thought they were still in the research phase
zzz
so thats good
dr|z3d
yeah, looking promising now.
zzz
speed wasn't even in my mental checklist
dr|z3d
as mentioned earlier, 85Mb/s from fast.com on a 0 hop.
dr|z3d
speed was the initial line of inquiry via rambler. poor speed was the issue, relative to purokishi. so I figured we should look at that before all else.
zzz
ok
dr|z3d
what we don't want is something that performs like false.i2p :)
zzz
sure, it's just opposite of the normal path of making it work then making it fast. But faster is usually better
dr|z3d
like I said before, open mind. when someone tells me speed's an issue, then that's what I run with.. make sure the platform is sound before we draw any other conclusions..
zzz
yup, good job
dr|z3d
the inference was that the proxy software was somehow at fault, so I wanted to rule that out.
zzz
do you think they've settled on a solution or is this just an initial experiment?
dr|z3d
we're testing out various options right now. if you're asking indirectly about timeframe, at a guess 1-2 weeks maybe.
zzz
wasnt really, but ok
zzz
hmm
zzz
I thought they were an all-i2pd shop
dr|z3d
only on account of the initial convenience, they're not hard set on that path.
zzz
but perhaps our rate limiting/filtering/banning infrastructure might be valuable. depends where they want to do it and what they feel they might need
dr|z3d
things like tunnel throttling and extended stats/graphs may influence them, yeah.
dr|z3d
(I've already raised that :))
zzz
there's a _lot_ of admin issues to work out before they should throw it wide open, thats a lot of work
dr|z3d
indeed.. I'm on it, worry not. :)
zzz
not for me to worry about anyway, and I never thought they were naive on what they were getting into
dr|z3d
they're big boys.. running 100 tor nodes means they're already in at the deep end :)
zzz
not just nodes but exits, yes
dr|z3d
exactly.
Xeha
does java i2p have "unique" local ip too, so you can filter with iptables? i forgot
zzz
yes
zzz
i2ptunnel option
Xeha
good :)
dr|z3d
0.0.0.0, 127.0.0.1, or anything else you'd care to configure, both ipv4 and ipv6 provisioned.
dr|z3d
and there's also support for multiple ips, and