&eche|on
&zzz
+R4SAS
+RN
+RN_
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+eche|off
+not_bob_afk
+orignal
+postman
+snex
+wodencafe
Arch
BubbRubb
Chrono
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest16752
Irc2PGuest33667
Irc2PGuest51880
Onn4l7h
Over
Sisyphus
Sleepy_
Teeed
aargh2
ac9f_
b3t4f4c3__
b4dab00m
bak83_
duanin2
duck
john231
leopold
makoto
mareki2p_
nilbog-
poriori_
profetik1
r00tobo
rapidash
shiver_
solidx66
thetia
u5657
uop23ip
vivid_reader56
x74a6
xHarr
zzz
new I2P research paper link.springer.com/chapter/10.1007/978-3-031-53472-0_30
zzz
PM me for PDF link
zzz
the paper seems to be all setup for their next paper where they might actually do something
zzz
they've also flopped the fast and high cap tiers, looks like I'll have to email them
orignal
what's your UDP socket send buffer size in SSU2?
orignal
we have found that 128K is very not enough
zzz
the final queue before the OS is codel with a max of 128-768 packets, depending on memory size, but it doesn't overflow, it will back up into the queues before it
zzz
or into the per-connection queues. can't remember
zzz
but you definitely want some anti-bufferbloat AQM or codel or something there
orignal
no, I meant something else
orignal
not about SSU2 ptorocol
orignal
but buffer size of UDP socket
zzz
hmm
zzz
not sure we can get to that from java
orignal
you use a signle UDP socket for everyting. right?
orignal
how do you send a packet?
orignal
sync or async?
orignal
do you call "send"?
zzz
yes
orignal
void setSendBufferSize(int size)
orignal
that's the function
orignal
did you ever mesure how long it takes?
orignal
we have discovered this issue today that "sendto" takes time
zzz
yeah we do call that to set it to 256K
orignal
we had 128K but it's not enough for high loaded routesr
zzz
no haven't measured time I don't think
zzz
but if a packet stays too long in the queue, codel will start dropping
orignal
I didn't think too
zzz
if the queue backs up, it will push back into the per-connection queues
orignal
but Vort showed it might up to 50 milliseconds
orignal
so buffer size matters
zzz
you running the sender in a separate thread?
orignal
no
orignal
same as all SSU2 processing
zzz
then why have a queue?
orignal
because I assumed that send takes zero
orignal
queue?
orignal
I din't metion queu
orignal
we just found that send is slow
orignal
sometimes
orignal
so think about buffer size
orignal
be thin to set to 4M for X routers
zzz
oh you don't have a queue at all, got it
orignal
no I don't think so
zzz
how would I know if it's not big enough?
orignal
easy
orignal
if you set your socket to non-blocking mode
orignal
"send" will return error instantly if buffer is full
orignal
that's what we are palying with
zzz
ok, but you don't want bufferbloat in the OS. Better to have it back up into my code, where I can do dropping based on priority and codel
zzz
huge buffers anywhere are bad
orignal
4M is not huge
zzz
it's 2800 x 1500 byte packets
zzz
I wouldn't want more than about 1/10 of a second of packets in the OS buffer
zzz
maybe less
zzz
none of this will happen for us unless the user really gets his bandwidth limits wrong
zzz
whats the linux default buffer size?
zzz
104 KB for me for DatagramSocket
zzz
anyway, regardless of your buffer size setting, I recommend a codel priority queue and a separate sender thread
zzz
you can never totally fix buffering problems by making the buffer bigger. If you're lucky, maybe it happens less often, but you may just be causing bufferbloat which makes the problem worse