shiver
Moin, dr|z3d the browser usage is still as high as before when i let it sit for a while but it's not that important, i use 30s or more refresh and disable the animation etc. again.
shiver
known peers is now around 6k down form 12, job lag is lower but i also have less traffic/tunnels
shiver
*from
shiver
from the logs i see that "reject hop throttle" is much more active but that's probably the changes that were made
dr|z3d
hi shiver
dr|z3d
ok, higher refresh may be the way to go for now for the sidebar.
dr|z3d
known peers down, that's a good thing.
dr|z3d
less traffic/tunnels, that's a variety of optimizations including hop throttles, temp banning peers that make too many tunnel requests, and possibly the results of disabling ssu1. it'll adjust over time.
dr|z3d
there's a lot of routers out there right now making a huge amount of tunnel requests and sharing no bandwidth to speak of.. those are what we're targetting most.
dr|z3d
to relax the hop throttler, you can add the line: router.minThrottleTunnels=5000 for example, where 5000 is the number of transit tunnels before the throttler kicks in. it's currently configured at 2500 routers by default for your class of router.
dr|z3d
the main thing appears to be the reduction in your job lag which was the issue you reported (sidebar refresh aside), so that's a win! :)
dr|z3d
the rough target for unreachable peers is max around 20% of known peers.. once your known peer count starts rising above 5K, that percentage tends to rise with it, so there's little advantage to having more than 5-6K peers in your netdb.
dr|z3d
also note that as the number of peers in the dht -> 127.0.0.1:7657/debug#dht scales, we're now reducing the expiry time for routers to keep the known peers at a reasonable level.
shiver
dr|z3d, idk that the job lag is actually lower because too much changed, router is under much less load.
shiver
is there an issue if i set router.minThrottleTunnels too high?
dr|z3d
no real issue, your router will just keep servicing transit tunnel requests with no regard to how fast they're made, but you'll still be throttling individual routers that make too many requests.
shiver
i mean 10k+ tunnels is no issue for my system but i think you want to distribute the tunnels more.
dr|z3d
thing is, when you get past around 5K tunnels, there's a lot of spurious requests happening right now.
dr|z3d
possibly bitcoin related, coming from L tier routers. crap.
shiver
before the update i saw X tier routers often use half my upload with 2MB/s for one tunnel
shiver
but that were all floodfill
dr|z3d
when you say before the update, 2.0.0.-2+?
dr|z3d
I mean, there's been a lot of frankly dodgy traffic on the network lately. That's what we're trying to fix.
shiver
with 12+
dr|z3d
well, keep an eye on your tunnels.. there's an adjustment period while your router recalibrates after disabling ssu1.
dr|z3d
you can also add the following lines to /configlogging to keep an eye on requests that are being dropped:
dr|z3d
net.i2p.router.tunnel.pool.ParticipatingThrottler=DEBUG
dr|z3d
net.i2p.router.tunnel.pool.RequestThrottler=DEBUG
shiver
okay
dr|z3d
the main thing to keep in mind right now is that 10K tunnels is abnormal. 4-5K tunnels is a good load under normal circumstances.
shiver
before 2.0.0.0 avg was maybe 2k xD
dr|z3d
yeah, we think the recent huge increase has something to do with bitcoin.
shiver
and that one guy with his OS
shiver
150 tunnels
dr|z3d
yeah, I don't think prestium is the issue, but it might be a minor contributor.
shiver
dc'd
shiver
thank you for the advice again, i'm probably afk for longer/the day.
dr|z3d
no worries, shiver
y2kboy23
dr|z3d I did a thing! gitlab.com/y2kboy23/I2P.Plus/container_registry/3770855
dr|z3d
let's see what you got there, y2kboy23 :)
dr|z3d
looks interesting, is there a docker image in there somewhere?
y2kboy23
There is.
y2kboy23
Got the builder process running locally and figured out how to use the Gitlab CI to successfully build the images and then upload to their registry
dr|z3d
great stuff
dr|z3d
hub.docker.com next?
y2kboy23
I was attempting to build ARM images but I ran into a few snags with it
y2kboy23
That should be fairly easy. Just have to add secret variables to Gitlab and then update the yml file for dockerhub.
dr|z3d
ok, great. well done. when you've got some instructions for simple deployment, let me know, I'll put them up on skank.i2p and i2pplus.github.io
y2kboy23
We could just use Gitlabs registry. Would work the exact same there versus on Docker Hub.
y2kboy23
Might get more potential exposure on Docker Hub
dr|z3d
up to you, it's your project, but hub.docker, yeah, is likely going to be found easier.
dr|z3d
you could dip your toe in the water and upload a docker image to postman's tracker to see what sort of demand there is for it.
dr|z3d
*upload a docker image torrent
dr|z3d
uploading to postman will also get you some initial exposure. and announcing on reddit never hurt.
dr|z3d
reddit/zzz.i2p/i2pforum.i2p and ramble.pw/ramble.i2p
y2kboy23
I'm not sure that can be done. Deploying via Docker/Kubernetes is done via a URL.
dr|z3d
ok
dr|z3d
that's what I was missing when I looked at the gitlab page. the link to the 103MB's worth of docker image :)
y2kboy23
zzz.i2p is not a bad idea. I need to find a way to pull upstream commits. I'm using the Gitlab IDE and they really don't make it easy. I just tried hooking NetBeans up to my fork but I have some issues that need to resolve first.
y2kboy23
266 MB when I download it. Not sure why they're showing 103MB
y2kboy23
Which is around the same size as i2p
dr|z3d
I always pull the relevant upstream commits, so you might not want to bother with those.
dr|z3d
if you do want to bother, you'd need a separate branch that pulls from the upstream repo.
dr|z3d
i have, in effect 2 local branches.
dr|z3d
dev, for i2p+, and upstream.
y2kboy23
For testing the images, I was going to attempt to. I could just update my side to git clone into the imaged and then compile there.
dr|z3d
I pull from upstream to my local upstream branch, and then cherry-pick the commits from upstream to my dev branch.
dr|z3d
what can I tell you? you may spend more time than you'd want manually merging upstream commits, it's mostly not straightforward given the changes I've made.
dr|z3d
I do try to remember to tag my releases, not sure how that translates on gitlab, though.
y2kboy23
The one issue I have with i2p, is every commit creates an image and is assigned to the "latest" tag which is the default tag for docker. Good practice is to have latest assigned to stable and then have different tags for development
dr|z3d
sure, release and latest make sense.
dr|z3d
or just release, with the update mechanism enabled so users can update themselves.
y2kboy23
In the docker world, images are ephemeral. You mount locations for the data that does matter and then the image can just be tossed away when no longer needed or a new version is available.
dr|z3d
ok, well, latest might not be so bad, then.
y2kboy23
You certainly can update within the image, but those changes aren't really "sticky"
dr|z3d
what about things like netdb and profiles? persistent across restarts?
y2kboy23
Those are in persistent storage. For my setup, it's just mounted on the host, so Docker translates that from the host to the image.
dr|z3d
ok, good, because running an image without at least those dirs persistent would be painful both for the user and the network.
y2kboy23
Yep. The Docker.md file actually discusses that. I have some recommended changes there too. I had a rough time with ports and getting the dang thing integrated when I first deployed a router.