@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest10850
Irc2PGuest19353
Irc2PGuest23854
Irc2PGuest46029
Irc2PGuest48064
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4__
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
mittwerk
plap
poriori
profetikla
rapidash
shiver_
solidx66
u5657_1
uop23ip
w8rabbit
weko_
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
eyedeekay
*on
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
:)
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
zzz
keepalive part 2 MR: git.idk.i2p/i2p-hackers/i2p.i2p/-/merge_requests/176 have fun