~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@orignal
@postman
@zzz
%Liorar
%acetone
+FreefallHeavens
+Onn4l7h
+Sh0ck
+bak83_
+leopold
+r00tobo_BNC
+uop23ip
+xHarr
Arch
BeepyBee
BubbRubb
Danny
DeltaOreo
H20
Irc2PGuest16752
Irc2PGuest33667
Irc2PGuest97218
Maylay
Meow
ac9f_
anontor
b4dab00m
eyedeekay_
halloy13412
john231
makoto
nZDoYBkF
nilbog-
not_bob_afk
ntty
poriori_
profetik1
r00tobo[2]
shiver_
simprelay
solidx66
thetia
tr
u5657
vivid_reader56
zer0bitz
dr|z3d
usability feature in the pipes for + users in advanced mode.
dr|z3d
you'll be able to toggle tunnel ids on /tunnels if you don't want to see those, and the toggle state will persist via localstorage.
dr|z3d
zzz: ever thought about indicating per-tunnel latency on tunnels? i2pd does something like that.
dr|z3d
unrelated, you don't need separate markdown.css files for susimail, just add the blockquote class to the existing susimail.css files.
dr|z3d
also unrelated, on git.idk.i2p/i2p-hackers/i2p.i2p/-/merge_requests/173/diffs this at first glance looks wrong:
dr|z3d
case MessageStatusMessage.STATUS_SEND_FAILURE_LOOPBACK:
dr|z3d
return "local loopback denied, set i2cp.disableLoopback=true to test sending to yourself through tunnels";
dr|z3d
shouldn't it be "set i2cp.disableLoopback=false ..." ?
zzz
I don't think we measure per-tunnel latency
dr|z3d
is it worth considering? maybe we can detect failing and or malicious tunnels that way and drop them?
zzz
how do you propose to measure?
dr|z3d
that's a good question. send a "pulse" packet every so often and see how long it takes to get to the endpoint?
dr|z3d
how are you measuring latency, orignal?
zzz
what endpoint?
zzz
how would the data be used, other than console display, which on its own is pointless?
dr|z3d
you'd set a ceiling, and drop tunnels if they exceed that. maybe the ceiling would be derived from the mean latency.
dr|z3d
just looking at i2pd's code right now.
zzz
by the time you have decent data your 10 minutes is up anyway
dr|z3d
they have GetMeanLatency()
dr|z3d
also:
dr|z3d
/** @brief return true if this tunnel's latency fits in range [lowerbound, upperbound] */
dr|z3d
bool LatencyFitsRange(uint64_t lowerbound, uint64_t upperbound) const;
dr|z3d
bool LatencyIsKnown() const { return m_Latency > 0; }
dr|z3d
bool IsSlow () const { return LatencyIsKnown() && (int)m_Latency > HIGH_LATENCY_PER_HOP*GetNumHops (); }
zzz
assuming you can get decent data at all
dr|z3d
if it took that long to get a decent read, i2pd wouldn't be doing it.
zzz
i don't need code snippets i need a proposal on how to do it
dr|z3d
I'm trying to grok what i2pd is doing, it looks like they already have the answer.
zzz
and the measurement is at what layer?
dr|z3d
i2np?
zzz
tunnel tests?
zzz
which ofc involve 2 tunnels
zzz
so then you need to calculate the mean of all tunnel tests, divide by 2, compare to the mean of all that tunnel's tests, subtract out the mean of each of the paired tunnels you tested with...
zzz
something something statistics
zzz
or do you allocate 1/6 of the tunnel test time to each peer, then over time you have an avg per-peer latency, and you add up those for a synthetic estimate for the tunnel?
dr|z3d
yeah, sounds about right, but orignal is more qualified to illuminate this discussion than me. like I said, i2pd have something that looks functional :)
dr|z3d
at the moment they set a static max at 250ms.
dr|z3d
which is probably fine on a slow router, but seems a bit high for something faster.
dr|z3d
that sounds more accurate, no? it also sounds like we also get per-peer latencies which could help with peer selection?
zzz
is that safe to bias selection on latency? or can a peer give you good service to attract your tunnels?
dr|z3d
if a peer's giving you good service, great. let's assume that's the default. if a peer stops giving you good tunnels, then the latency should reflect that, no?
zzz
depends if you're using latency just to kick slow peers out, or you're picking the least latency for your tunnels
dr|z3d
we don't want to reject peers that give reasonable service, or prioritize those that give exceptional service per se, we just want to avoid those that give shitty service.
dr|z3d
I'd say a combination of both, with maybe a toggle that determines whether we want lowest latency or not?
zzz
whatever. it has to be designed bottom-up, not start with 'we should put this in the console'
dr|z3d
I wanted to start a discussion, but sure, a solid proposal would help things along, but maybe i2pd's already done most of the work there for a working implementation.
zzz
the two projects have very little in common on profiling
zzz
either per-peer or per-tunnel
dr|z3d
sure, that's not to say we can't appropriate some of their ideas where they make sense.
dr|z3d
and tunnel profiling looks like a good one.
zzz
we do measure pt-pt latency in SSU2, but we don't feed that into the profile, and it could be problematic for the reasons above