orignal
so we have found the problem
zzz
ok
zzz
zlatinb, thanks for the great testnet work yesterday
zlatinb
np it was fun
zlatinb
except for the "apt get openssl libboost-all-dev" which took forever
zzz
sure I can try to find the ntcp-only problem, will put it on the list
zlatinb
should have done it in the first container before the cloning :)
zzz
I see an i2pd checkin last night, is that the fix?
zlatinb
yeah, verified
zzz
as in tested on the testnet?
zlatinb
out of ~600 tests only 1 failed, I didn't bother investigating it
zlatinb
yes
zzz
so it's an SSU problem?
zlatinb
looks like it; I imagine it renders the object pool foobared
zlatinb
but I know next to nothing about std and boost
zzz
is this object pool isolated to SSU or it foobars the whole router?
zlatinb
idk
zzz
need to know how to avoid the problem from our side
zlatinb
need a working ntcp-only testnet for that lol
zzz
orignal, how can we work around it?
orignal
zzz give the priority to NTCP2
orignal
basically SSU dropped too many packets
orignal
that's was the rpoblem
orignal
this pool problem is specific to SSU
orignal
how we merge fragments
orignal
I will rewrite it later
zzz
what versions have the problem?
orignal
0.9.52
zzz
only?
orignal
yes
zzz
ok
orignal
I tried to optimize memory usage for it
zzz
so nothing about STBM or anything like that, it's just an SSU thing?
orignal
basically I copied code working well for NTCP2 to SSU
orignal
but SSU works differentyl due the fragments
orignal
it's only SSU thing
orignal
packet drops
orignal
maybe there is something else
orignal
but zlatinb doesn't see any issues in testnet after this change
zzz
sure, there always could be more bugs ))
orignal
and ofc I didn't see any problem with that routers from the list because I used NTCP2
zzz
good job finding it
orignal
for 1 hop
orignal
this job is not done yet
orignal
because I need to find out what exatcly wrong in SSU with fragments
orignal
maybe there is one more old bug
orignal
but it doesn't affect functionality
zzz
ok
orignal
but also I see another issue
zzz
I can use NTCP2 only for connections to i2pd 0.9.52
orignal
no, never mind
orignal
yes, it would be nice
zzz
but maybe should also avoid i2pd 0.9.52 in tunnels
orignal
up to you
zzz
do you plan to do a release soon to fix it?
orignal
no. let's wait for regular release
orignal
also you might use 0.9.52 in tunnels if they are connected trough NTCP2
orignal
I don't know if you have the code for it
zzz
do you know how many SSU packets are being dropped? about what % ?
zzz
yeah but I don't know how the 2nd and 3rd hops are connected
orignal
I would day 1/20
zzz
me either, will have to look
orignal
*say
orignal
also remember that i2pd always prefer NTCP2
zzz
do things get corrupted and it starts dropping everything? or it's just random?
orignal
if possible
orignal
random
zlatinb
I didn't count but eyeballing before the fix about 40-50% of the java tunnel tests failed
zzz
ok
orignal
it's not corrupted compeletely
zzz
we were going to release on feb. 28 but we could probably do it on the 21st instead
orignal
just override some start of buffer for some packets
zzz
whats the earliest you could release?
orignal
most likely by multi-fragments
orignal
I need to ask R4SAS
orignal
if he is not busy
zzz
I think 21st is the earliest we could do it
orignal
I can do at any time
orignal
21st is fine
orignal
also it affects to data messages only
orignal
and not like peer tests, etc.
orignal
also Tunnel creation success rate: 73%
orignal
after rebuild on some VPS
zzz
but you could go before us
orignal
I want to mark it as 0.9.53
orignal
maybe few days before yes
orignal
but not more
zzz
ok
zzz
workarounds tested and pushed
orignal
works?
orignal
implemented clock skew change for NTCP2
orignal
Bob sends SessionCreate now and then closes the session