Here is what I see from my experience(no scientific tests conducted).
- With prefer_tcp I almost always hit my top speed consistently. Youtube
videos don't play most of the time. OTher browsing is possible without
noticing delays.
almost always ~100KiB/s lower. Youtube videos start playing and then
buffering and then playing. And after a while youtube's algo decides to
downgrade to 360p or less. Manually choosing 720p it makes video playing
for a few seconds and then buffering again. During all this my torrent
speeds drop to around 600KiB/s and rarely less than 550KiB/s.
I download a torrent at a time with no seeding others.
auto-throttling or I need to check other settings too.
Post by Arvid NorbergOn Thu, Sep 8, 2016 at 7:37 AM, sledgehammer999 <
Post by sledgehammer999I don't have low-level network knowledge nor have I searched μTP algos
much. Only descriptions so I might be totally off point.
Is one of the purposes of μTP to back-off automatically if the user wants
to use the bandwidth to browse or use some other network intensive
application at the same time?
yes, but there are cases were it will degrade to behave like TCP (and only
use packet loss as congestion signal).
Post by sledgehammer999If yes, what libtorrent settings affect this? Does mixed_mode_algorithm
affect this?
mixed_mode affects this, yes. By default it's supposed to be set to
throttle TCP connections based on the throughput on uTP connections
(proportionally). This logic is basically a heuristic, and it could use a
lot more tuning and more complex heuristics probably. For any high-end
system (say, a server in a colo with good connectivity) it most likely
makes sense to disable the mixed mode (by setting it to prefer TCP).
Post by sledgehammer999For example, is it supposed to back off automatically if someone is
watching youtube videos(at least at 720p)?
I think the default settings don't do that.
Yes, but with some caveats. It works best for outgoing traffic, because
that's typically where most users see queuing of packets. uTP uses one-way
delay measurements to estimate the congestion. This lets it detect
congestion a lot earlier than TCP (because the queue has to fill all the
way up for a packet to get dropped).
However, on a link where there are no queues at all, uTP won't ever
experience any delay and only see packet loss. This effectively disables
the "background-transfer" property.
Inbound traffic may be less likely to have large queues at the bottlenecks.
At least my impression of DSL modems is that they primarily have large
queues for outbound packets. Once the queues are small enough, the
effectiveness of uTP back-off will also be diminished (and again, it will
resort to TCP-like loss-based congestion control).
So, to answer your question, it doesn't necessarily work in all situations,
just in most of them. And probably more likely in situations where it
matters most (slow links).
If anyone's interested in more details, I wrote down some features of uTP
here: http://libtorrent.org/utp.html
--
Arvid Norberg
------------------------------------------------------------
------------------
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss