IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/01/21
@eyedeekay
&Irc2PGuest88200
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+dr|z3d
+eche|off
+hagen
+mareki2p
+orignal
+postman
+radakayot
+segfault
+snex
+weko
+wodencafe
Arch2
BubbRubb1
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest30001
Irc2PGuest53192
Irc2PGuest59134
Irc2PGuest59581
Onn4l7h
Onn4|7h
SigSegv
Sisyphus
Sleepy
acetone_
aeiou
ardu
b3t4f4c3__
bak83_
boonst
carried6590
cumlord
death
dr4wd3
duck
enoxa
eyedeekay_bnc
not_bob_afk
onon_1
phil1
phobos_
pisslord
poriori
profetikla
qend-irc2p_
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
x74a6
dr|z3d zzz: any scope for shunting some of the eventpumper load onto NTCP Finisher threads? they seem underutilized right now.
dr|z3d NTCP reader threads are being exercised more, writer threads, not so much, and then finisher threads least of all.
zzz dr|z3d, we just did a big shunting with the ntcp write changes
zzz there's no need to balance workload across threads
zzz and jogger would tell you the opposite
dr|z3d ok, just noticing the finisher threads are less noticeably less utilized than both the reader and writer threads.
dr|z3d *noticeably less utilized
dr|z3d if I constrain the pumper thread it's happy to use around 50% of one core under loads of ~1MB/s
zzz probably a candidate for removal of the finisher threads
zzz jogger hates all of it
dr|z3d yeah, jogger's not a huge fan of the "let's throw threads at it approach", understandably, given android.
dr|z3d android/arm
dr|z3d more arm than android, but yeah.
zzz not sure if arm is worse at threads than x86, or if it's just worse at everything
dr|z3d probably the latter for the most part, given the specs of the usual candidates vs x86 (raspberry pis)
dr|z3d still, if the finisher threads aren't serving much purpose, sounds like a reasonable idea to eliminate them.
zzz just takes time to analyze and test, and of course be extra careful not to introduce deadlocks