IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/12/29
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+not_bob_afk
+orignal
+weko
FreeRider
Irc2PGuest71506
Leopold_
Onn4l7h
Onn4|7h
T3s|4_
T3s|4__
aargh2
anon
cancername
eyedeekay_bnc
hk
profetikla
shiver_
u5657
x74a6
R4SAS Received: 4.41 GiB (14051.13 KiB/s)
R4SAS 15 minutes uptime
R4SAS 110+ Mbit/s
zzz back, and posted a big update on github.com/bitcoin/bitcoin/issues/26754
dr|z3d remind me where we're setting build timeout and concurrent builds, zzz?
zzz the 13 is in BuildExecutor
zzz the 10 or 5 sec is in BuildRequestor
zzz I'm thinking the 2.6 builds/sec guidance I gave to orignal may be too high
dr|z3d ok. here request timeout is 8s or 10 if isSlow, first hop timeout is 5s or 8s if isSlow().
zzz prior to March it was 1 per sec
dr|z3d these builds could also be local tunnels as well as part tunnels, no?
dr|z3d in buildExecutor, concucurrency is 10 for isSlow or cores <= 4, or Math.max(cores*3,16) here.
dr|z3d I've tweaked the participating throttler - if the requesting router is K,L or unreachable, they now get a reduced budget which works out around 5 requests per 220s.
dr|z3d conversely, O,P and X tier routers get a bit more latitude.
zzz these limit are for our local tunnel builds
dr|z3d right, so basically everything we build, be it client tunnels, expl. tunnels or part. tunnels.
zzz Requestor + Executor = our tunnels. Handler = part. tunnels, plus replies of our buidls
dr|z3d ah, ok
zzz we don't "build" part. tunnels. we "handle"
dr|z3d gotcha
dr|z3d so requestor and exexcutor can probably be ignored, since local tunnels aren't the issue, no?
dr|z3d at least not the issue in java i2p, maybe there's an issue in i2pd-land where there's no limits.
zzz not right. The issue I'm exploring is limiting local tunnel builds and possibly adjusting that and the guidance I gave to orignal
zzz for the case of bitcoin+java, and for giving the best advice I can to i2pd for bitcoin+i2pd
dr|z3d ok, so possibly necessitated because bitcoin and you want a level playing field. ok.
zzz the thinking in March was that X25519 short build msgs are much smaller and less CPU than the old days, so faster build requests are fine
zzz but perhaps in a collapse scenario it's not fine
zzz and even without a local bitcoin app, we don't want to be part of the problem
zzz when the network is collapsing
dr|z3d what's the downside of reducing concurrent builds?
zzz slower startup
zzz I think it's fine normally but we should slow down after repeated failures
dr|z3d I was thinking the same thing. start normally, and scale back in the event of sustained failure.
zzz Blinded message
zzz Blinded message
zzz but we're not using it for any timing adjustment
zzz I'll think about it
dr|z3d ok, I've got max fails here at 5.
orignal yes, I'm working on it
orignal another suggestion from weko_
orignal to select first hop with less number of build requests
zzz please review my post at github.com/bitcoin/bitcoin/issues/26754 and comment if you have anything more to say about it, thanks
dr|z3d I think they might need it spelt out to them what a reasonable limit for transit tunnels and approx b/w share might be. Definitely way north of 20.
dr|z3d no less than 500 transit tunnels assuming .5MB/s share, perhaps.
zzz it's too messy to adjust the max requests during congestion but I think I can adjust the quantity which will do the same thing
dr|z3d sounds good
zzz done, -13-rc
dr|z3d *thumbs up*