@eyedeekay
+RN
+T3s|4
+Xeha
+acetone
+orignal
+weko
Hikari
Irc2PGuest67835
Irc2PGuest97144
Leopold
Minogami
Onn4l7h
Onn4|7h
R4SAS
T3s|4_
anon4
eyedeekay_bnc
idk
j6
not_bob_afk
profetikla
qend-irc2p
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
ok
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*