@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+not_bob
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest15271
Irc2PGuest28511
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb_
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_1
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
dr|z3d
zzz: PBQ for NTCP seems like it could do with a look
dr|z3d
it doesn't matter how large you configure the buffers, at some point on a fast router they will become permanently clogged.
dr|z3d
in other news, obscuratus' lookup patch appears to make a worthwhile difference to leaseset lookups.
obscuratus
dr|z3d: I've got a better version of that patch. I'm testing it now.
dr|z3d
great, obscuratus
dr|z3d
it's been a long-standing issue that b32s especially never resolve on first attempt. good that it's getting some attention.
obscuratus
I'd still like to find a more solid solution, but it's complex.
dr|z3d
I think retrying is fine, not sure you need a delay specifically, maybe just a fixed number of retry attempts.
dr|z3d
bumping up the floodfill lookup concurrency may help.
obscuratus
dr|z3d: It's happening really fast. Just not quite fast enough.
obscuratus
If you have your stats on full, check netDb.storeRecvTime. For me, I'm seeing around 1 ms.
dr|z3d
Around 171 microseconds here.
obscuratus
dr|z3d: Interesting data point. That's much longer than I was anticipating.
dr|z3d
microseconds, obscuratus, not milliseconds :)
obscuratus
Oh, good.
dr|z3d
so almost 6* faster than what you're seeing.
dr|z3d
I'm hitting several floodfills concurrently with the query, so that will help.
obscuratus
So, your netDb.storeRecvTime is reading something like 0.171?
zzz
almost to the top of my list guys
obscuratus
:)
dr|z3d
it reads 171m
dr|z3d
m being microseconds in this context.
dr|z3d
to 2 decimal places.
dr|z3d
so 171.35m for example.
obscuratus
OK.
obscuratus
So, that time is the real time elapsed for runJob in HandleFloodfillDatabaseStoreMessageJob (otherwise refered to as HFDSMJ)
obscuratus
When ISJ (IterativeSearchJob) starts a search, it's asking the I2P network to reply back with a DSM (Database Store Message).
obscuratus
When the DSM is processed as an incoming message, we don't send it back to the ISJ. We process it on a different thread for incoming DSMs.
dr|z3d
I see mostly fail for RI lookups running via ISJ.
obscuratus
ISJ tries to match it's search with the incoming DSMs.
dr|z3d
Not sure if that's expected behavior.
obscuratus
As soon as ISJ sees that the DSM it's looking for has come in, it declares success. But the DSM hasn't been stored yet.
obscuratus
It sounds easy, but I'm finding it really hard to make ISJ wait for success to be after it's stored to the Persistent Data Store.
obscuratus
dr|z3d: All callers to ISJ expect the deliverable to be a lease stored to the persistent data store. But we nearly always jump the gun on when that happens.
dr|z3d
zzz will sort it, of that I'm sure. you've outlined the issue, provided a patch, and run some tests. all good. :)
dr|z3d
obscuratus: yeah, I hear you. I haven't gone in quite so deep, but something around lookups has struck me as sub-optimal for a long while now.
eyedeekay
zzz I have a question, is it possible for me to add/replace/remove something on the system tray menu from inside of a plugin?
eyedeekay
I'm looking at the javadoc and I think I'm closing in on a way, but I'd like to know if I'm overthinking it
zzz
no
zzz
don't think so
eyedeekay
OK. I can work around it to do what I want to do by just making routerconsole.browser run my jar which is how I'm doing it in Easy-Install, but I'm not sure that's the best way for a plugin to do it
eyedeekay
Maybe I just make my own traymenu for the plugin itself
zzz
there's definitely no DTG API for adding/removing menu items. It's all private and hardcoded
zzz
eyedeekay, please review/fixup/add to my recent roadmap edits
zzz
at your convenience, no rush
eyedeekay
Will do