@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hagen
+hk
+not_bob_afk
+orignal
+postman
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest31001
Irc2PGuest59134
Irc2PGuest66424
Irc2PGuest74564
Irc2PGuest81747
Leopold
Nausicaa
Onn4l7h
Onn4|7h
Sisyphus
Sleepy_
SoniEx2
T3s|4_
T3s|4__
Yotsu
anon3
b3t4f4c3__
bak83
boonst
cancername
carried6590
cumlord
eyedeekay_bnc
l337s
onon_1
plap
poriori_
qend-irc2p
r3med1tz-
radakayot_
rapidash
rat
scottpedia
segfault
shiver_
solidx66
trust_
u5657_
uop23ip
w8rabbit
wodencafe2
x74a6
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