@eyedeekay
+R4SAS
+RN
+T3s|4
+orignal
+weko
Hidenet1
Irc2PGuest33877
Irc2PGuest68850
Leopold
Onn4l7h
Onn4|7h
ProRu
T3s|4_
acetone_
anon1
eyedeekay_bnc
j6
not_bob_afk
profetikla
qend-irc2p
x74a6
zer0bitz
dr|z3d
zzz: back to the prefer udp proposition.. we already do peer tests, so how much work would it be to extend the tests and disable a transport if it's proved to be unreliable/dead?
dr|z3d
oh, no zzz.
dr|z3d
> zzz: back to the prefer udp proposition.. we already do peer tests, so how much work would it be to extend the tests and disable a transport if it's proved to be unreliable/dead?
zzz
dunno. I told orignal that if we have repeated failures on one transport we'll prefer the other one, but on closer inspection that's not really true
zzz
can't have the transports self-disable or you'll end up with none
zzz
key is to not get "stuck"
dr|z3d
that's true, but if neither transport is working you're already up stuck avenue :)
zzz
can't allow a transient condition to break things and require a restart
dr|z3d
that's also true. we'd need to do repeat tests over the course of an hour or more I guess, and if a transport is disabled, carry on testing and re-enable it the tests start working again.
zzz
have to track consec. OB failures, or have failure rate stat. Then if limit exceeded, bid low, but only _most_ of the time, b/c you need to keep trying and not get stuck
zzz
wouldn't be peer test, and we don't have peer test for TCP. Just keep track of OB success
dr|z3d
ok
zzz
we've never tried to really deal with blocked TCP. In theory if one transport fails quick enough we'll try the other one, so things work, just a lot slower. As jogger discovered though the timeouts may not be dialed in enough for that to work well
dr|z3d
learnt a new git trick today. -> git cherry-pick -x -X theirs <commit hash>
dr|z3d
if there's a conflict with an upstream commit you're trying to cherry pick and you want to force it, knowing it supersedes yours, that's the command.