~dr|z3d
@RN
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@not_bob_afk
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Irc2PGuest92669
+Xeha
+cumlord
+j6
+onon
+profetikla
+r00tobo
+snex
+uop23ip
An0nm0n
Arch
Danny
DeltaOreo
DiCEy1904
Irc2PGuest45008
Irc2PGuest68141
Irc2PGuest71319
Irc2PGuest91332
Irc2PGuest92810
Onn4l7h
acetone_
anon2
anontor
anu
bak83_
boonst
goose
itsjustme
mareki2pb
no
poriori_
qend-irc2p
shiver_
u5657
unwr
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