#saltr (irc2p) | I2P+ 2.7.0-11+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

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.