Yat Ho

> Either Transmission is behaving badly by trying to initiate unwanted/unnecessary connections, or Transmission is behaving poorly by unnecessarily responding to poor client requests. I have been looking over this...

Related to #6910.

So Tr4-Tr4 speeds are often powers of 2...? Also I'm curious about the difference between uTP and TCP connections.

Let me get this straight before the discussion gets too messy: It's fine if you mention previous Tr4 release for comparison with the nightlies. But if you are going to...

Hmm, there's definitely something weird going on, probably with the upload code. I tried to repeat your test in https://github.com/tearfur/transmission/tree/tmp (TCP, 2 Tr4 clients on the same machine, `RelWithDebInfo`), and...

Just brainstorming, haven't had time to look into this more deeply yet. I think this is a more likely bottleneck than the bandwidth code: https://github.com/transmission/transmission/blob/a76a07ae992eb7a31435b7087c8ecfba50c1c33c/libtransmission/peer-msgs.cc#L1790-L1806 > Increasing `Increment` to 65536U...

Just an update. It's pretty clear to me that the reason for the 16MB/s cap for TrTr transfers is because our client `reqq` (BEP-10) value is hard-coded at 512. https://github.com/transmission/transmission/blob/3e9f5f614a875aae987235d3836d0ca555a80d80/libtransmission/peer-msgs.cc#L181...

Raising the value will solve a big part of the problem. And there's always more to it 😉

That doesn't mean much, it's just a fail-safe against an invalid value. I expect to have a PR up soon that raises this value to 2000 (matching libtorrent) and allow...

> If upload speed corresponds so directly to REQQ, seems like you'd be stuck at 64MB/s peak vs current situation. No? Yes, so that's why other changes are needed to...