IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2024/01/14
@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest43426
Leopold
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
aargh2
anon2
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb
not_bob_afk
plap
poriori_
profetikla
r3med1tz-
rapidash
shiver_
solidx66
tr
u5657
uop23ip
w8rabbit
x74a6
zzz eyedeekay, thanks for the reviews; note that email from gitlab still seems broken, for a couple weeks now
zzz anybody lobbying for other open MRs, the best way to do that is to either review or test and report results
eyedeekay Ack I'll get gitlab email reactivated as soon as possible
zzz thanks :)
zzz I think I"m unblocked on the phase 2 keepalive MR, trying to partition that out now
zzz I'd especially appreciate test reports on the snark bandwidth MR 164
zzz eyedeekay, what's your process on reviewing that one? you're just acking each file? should I be paying attention? any questions?
eyedeekay I am going through each file one-by-one to identify what is going on, simple changes like 'use new constructor' or 'move file to new location' or large deletions are being acked immediately, bigger and new section changes I'll have questions oj
zzz okeydokey
zzz doing final cleanup on the next keepalive MR, it's going to be about 1400 lines of diff
zzz do you need any background on what a "synthetic RED queue" is?
eyedeekay Couldn't hurt
zzz so a RED queue is random early drop
zzz we use it lots of places
zzz for active queue management (AQM)
zzz you want more on RED queues?
eyedeekay Maybe later after I have a closer look at that part
eyedeekay I am curious what conditions must be satisfied for it but maybe I can just see it by reviewing with that in mind
zzz ok then I'll just explain 'synthetic'
zzz the synthetic queue doesn't queue anything.
zzz it just reports if your attempt to "add" something to the queue would have failed because it did its RED thing, aka dropped
eyedeekay So it's dealt with before it enters a real queue?
zzz the other thing is that our synthetic RED queue is a bandwidth estimator, because that's how it's deciding when to drop
zzz so the synthetic RED queue is pretending to meter out what gets "added" to its fake queue, at the configured bandwidth
zzz if too much gets added at pmce, the fake queue starts to "fill", and the fake "add" starts to fail
zzz right
zzz if (syntheticREDQUeue.add(1000 bytes of stuff you want to send))
zzz add it to your real queue, or send it, or whatever
zzz else
zzz drop it or wait a while or whatever
eyedeekay So are there both "synthetic RED queues" and "real RED queues?" where the difference is the nature of the queue?
zzz the synthetic RED queue is not a queue at all. It doesn't queue anything. It just tracks how big the queue would be if it were real
zzz and acts the same as a real queue in that it tells you it dropped
zzz so if you want to limit something to a max rate, you can use the synthetic red queue to do that, without changing any of your internal queues.
zzz you just ask the synthetic queue, can I send this now or not
eyedeekay So there would be no point with a non-synthetic queue
zzz not ture, we use "real" RED queues in lots of places. See CoDelBlockingQueue and CoDelPriorityBlockingQueue
zzz the distinction is if you're metering to a configured bandwidth limit (snark and transports) or just need to manage queue size (elsewhere in the router)
eyedeekay Ok that was the first Q I had when you mentioned synthetic queues, are there also real ones
zzz yup
zzz the synthetic red queue comes from streaming SimpleBandwidthEstimator, it's used for the participating bandwidth limiter in transport.
zzz it's basically Westwood+, see the refs in the javadocs
zzz ofc on the receive side, we don't use it for dropping, only for bandwidth estimation. You don't drop stuff after you receive it ofc
eyedeekay Makes sense, thanks
zzz you can tell it's not a real queue because it has offer() but no take(), and offer() doesn't take the packet as an arg, only the size
zzz think of it as a little advisor that tells you how fast you're going and if it's too fast
zzz but the little advisor is really really smart because he wrote a bunch of papers about it in college ))
zzz long ago you could be the only leech with a bunch of seeds and you'd be fine
zzz but now we're so fast that you blow yourself up
zzz dr|z3d, I should have the new keepalive MR up today or tomorrow. I'm working on editing the big checkin comment from last time
dr|z3d zzz: great, looking forward to it. did you identify anything that might be causing issues with https on git.idk?
zzz The main thing was him announcing that http didn't work and wouldn't, even though it kinda did until I started getting 422's
zzz although MR 175 also helps on the failure cases
zzz have a little time today since the buffalo game got snowed out :)
dr|z3d I've never found not to work on git.idk
zzz some of the links are janky
zzz and now it redirects to https to log in
dr|z3d ok, maybe I'm not seeing that because I rarely login.
zzz if you're not logging in it mostly works, yes
zzz do you have any test reports on the snark bandwidth MR or were you not brave enough to try it? ))
dr|z3d haven't merged that one yet, though I'd like to, just waiting for it to be merged your end, as I'm manually merging patches and that one's a bit of a monster.. too much to go wrong.
zzz maybe we can talk somebody into it
dr|z3d he was busily acking each file earlier on, so maybe he's on the verge..
zzz see 3h above ^^^
zzz hmm is a 306 line checkin comment for keepalive enough?
dr|z3d less is more :)
dr|z3d unless less is somehow deficient. then less is less :)
zzz since there's no formal proposal or writeup anywhere else, this seems to be the best place