These are chat archives for anacrolix/torrent

9th
Jul 2018
Matt Joiner
@anacrolix
Jul 09 2018 00:19
I believe the dial timeouts are too high, so people who aren't receiving incoming connections may struggle.
I'm not sure the problem you're describing
There's a new perf that will help me, dump your /debug/perf here
Matt Joiner
@anacrolix
Jul 09 2018 00:34
client.go:600, set the timeout to ~15s based on my production testing
it could probably even go lower, i need to see other people's stats
Denis
@elgatito
Jul 09 2018 03:21
It just looks like randomness of 'range' in golang is causing this situation, like bad address is got in the start of connections initiations
Sometimes it starts with a few connections and then just stops after few seconds, then continues after a while and connections are raising
Matt Joiner
@anacrolix
Jul 09 2018 03:25
you think it's picking bad addrs from the pending addresses?
show me completedHandshakeConnectionFlags from /debug/vars after it's started working
but also /debug/perf
Denis
@elgatito
Jul 09 2018 03:27
sure, i will make another endpoint to print all the debug info, not just the /info
Matt Joiner
@anacrolix
Jul 09 2018 03:28
i thikn ur bundle already had those right?
i added prioritizing of peers a few months ago, i wonder if that's triggering bad behaviour for you
Denis
@elgatito
Jul 09 2018 03:28
that is a bundle with kodi log which is sometimes MBs
Denis
@elgatito
Jul 09 2018 03:29
no, should not, that was happening for longer time
Matt Joiner
@anacrolix
Jul 09 2018 03:29
ok
try lowering that dial timeout i mentioned above
try also setting the peer high water to like 3000
and send me those 2 items
Denis
@elgatito
Jul 09 2018 03:30
maybe 5% or something like that. i'm stopping the haulted torrent, start same torrent again and it's starting fine
high water is not connected to max connections limit?
Matt Joiner
@anacrolix
Jul 09 2018 03:30
ok so it is possible it's just bad peer addrs as i think you're suggestion. no it's not, ti's how many peer addrs to store in reserve
with that many trackers/dht, you have a huge number of peers right up front
increasing the number of addrs, may let more good peers through, altho i think bep40 should have taken care of that
i haven't tested it heavily
Denis
@elgatito
Jul 09 2018 03:42
i've set timeout for 15s and high water to 3000, looks like i've got it again, but now it's not going to 0, but to low speed, after few seconds it fires to full wifi speed
maybe we can have few timeouts for start of downloading and regular connection initialization?
Matt Joiner
@anacrolix
Jul 09 2018 03:45
i think it's just struggling to find successful connections with the huge amount of addresses
so the solution is to improve the addresses, or improve the speed you attempt them
bep40 attempts to reduce the impact bad actors can have giving bad addresses
teh dial timeout and half open limit increase the speed you can try addresses
i can't think of anything else to change
try raising your half open limit too
Denis
@elgatito
Jul 09 2018 03:50
to about 50?
Matt Joiner
@anacrolix
Jul 09 2018 03:52
sure. at some point you will struggle with file descriptors/overhead
Denis
@elgatito
Jul 09 2018 03:54
btw, why do we have straight time.Minute timeout at client.go:600 if we have a NominalTimeout config setting?
Matt Joiner
@anacrolix
Jul 09 2018 03:57
looks like it was forgotten in some refactoring :)
Denis
@elgatito
Jul 09 2018 03:59
i've reverted the timeout to see the difference. here is the debug info after waiting about 15 seconds downloading
the speed was about 1000kb/s, when regularly it's maxxed to about 5MB/s
Matt Joiner
@anacrolix
Jul 09 2018 04:25
i should bring back the reduced timeout function, it scaled the timeout based on how many spare peers there were
looking at your debug perf, you could get away with a timeout of anywhere from 2 to 8s
Denis
@elgatito
Jul 09 2018 04:27
i don't know if we need timeout more than 2s for establishing network connection (not handshaking)
Matt Joiner
@anacrolix
Jul 09 2018 04:28
handshakes never take more than 1s
i don't currently have a separate handshake timout i think
but it used to be about 4s
Denis
@elgatito
Jul 09 2018 07:12
will you make timeouts configurable? :)
Matt Joiner
@anacrolix
Jul 09 2018 10:23
Yeah definitely
I'll wire those config options in, make an issue for it