Opened 8 years ago

Closed 7 years ago

#4321 closed Bug (fixed)

uTP implementation is very slow.

Reported by: Username Owned by:
Priority: High Milestone: 2.70
Component: Transmission Version: 2.31
Severity: Major Keywords:
Cc: jch@…, thomas_reardon@…

Description

I did some tests, here are the results. There was one peer on large torrent and nothing else. All this on a reasonably fast channel (so I have a plenty time to do various measurements while being able to maintain constant ~40Mbps flows, up and down). Remote peer used uTorrent 2.2.1. Tests were conducted on Debian 6.0 and Ubuntu 10/11, Transmission used is 2.31 and latest SVN.

  • When using TCP only (uTP disabled), transfer easily achieves decent 400-450Kbytes/sec (channel allows even more, so it's remote peer who limits us to this speed).
  • When using uTP in same conditions, speed rarely reaches 100kbytes/sec. That is at least FOUR TIMES as slow as TCP.

I repeated these measurements several times and I'm pretty sure that same peer can reach ~450Kbytes/s via TCP but rarely reasches ~100Kbytes/s via uTP. Losing at least ~4.5 times to plain old TCP! It looks like Transmission's uTP implementation works really bad.

Attachments (1)

utp-write-on-demand.patch (3.7 KB) - added by ssiloti 7 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 8 years ago by livings124

  • Cc jch@… added

Adding jch to the cc list. He should be able to respond to this better than we could.

comment:2 Changed 8 years ago by jch

  • Resolution set to invalid
  • Status changed from new to closed

This is the expected behaviour, and actually the whole point of µTP — LEDBAT (the congestion control algorithm in µTP) is carefully designed to yield to other traffic.

Please read

http://www.pps.jussieu.fr/~jch/software/bittorrent/tcp-congestion-control.html

for more information.

-- jch

comment:3 follow-up: Changed 8 years ago by Username

  • Resolution invalid deleted
  • Status changed from closed to reopened

There was no other traffic. There was no congestion. Channel had good ping times. So it's just inefficient implementation. Hence reopening. If loss of speed by 4.5 factor is a "expected behavior" I would suggest to disable such a protocol by default, else people would blame Transmission as slow.

And let's say, uTorrent to uTorrent xfers do not have 4.5 times bandwidth penalty. It's Trnasmissuib to utorrent behavior only.

Btw, after carefully reading logs I found this:

Sun Jun 26 15:28:35 2011        error   UDP     Failed to set receive buffer: requested 4194304, got 262142
Sun Jun 26 15:28:35 2011                UDP     Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf
Sun Jun 26 15:28:35 2011        error   UDP     Failed to set send buffer: requested 1048576, got 262142
Sun Jun 26 15:28:35 2011                UDP     Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf

Could it be related to my issue? Due to this message I'm starting to suspect that for some reason Transmission couldn't keep up with filling UDP buffers in a timely manner or so. However strange thing is that TCP works fine without asking for huge buffers. Can you explain me what's going on?

comment:4 in reply to: ↑ 3 ; follow-up: Changed 8 years ago by x190

Replying to Username:

Sun Jun 26 15:28:35 2011        error   UDP     Failed to set receive buffer: requested 4194304, got 262142
Sun Jun 26 15:28:35 2011                UDP     Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf
Sun Jun 26 15:28:35 2011        error   UDP     Failed to set send buffer: requested 1048576, got 262142
Sun Jun 26 15:28:35 2011                UDP     Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf

Could it be related to my issue? Due to this message I'm starting to suspect that for some reason Transmission couldn't keep up with filling UDP buffers in a timely manner or so. However strange thing is that TCP works fine without asking for huge buffers. Can you explain me what's going on?

µTP via UDP being connectionless must have it's sockets set up by the code and therefore needs all the buffer memory it can get, which must then be divided among all µTP peers. µTP also being a work in progress needs your help to maximize this buffer, hence the log message. If you need more info regarding how to do this, please open a forum thread.

comment:5 follow-up: Changed 8 years ago by Username

I can see at least the following issues:

1) If I can remember well, uTP is enabled by default and even preferred by clients(?)

2) I bet most of Ubuntu users (and Mac as well?) will have a very little idea on "what this app mumbles about?". Not to mention that defaults will always prevail, no matter how many times you flood the log. I guess I'll be not first and not last person to discover that Transmission is slow, because it is (by default).

3) Other clients are working better without all these system-wide tricks, this implies there should be way for some better implementation of the same things. Correct me if I'm wrong, but, say, uTorrent does not requires anything like this, etc and able to achieve much better speeds under same conditions.

comment:6 in reply to: ↑ 4 Changed 8 years ago by jch

µTP also being a work in progress needs your help to maximize this buffer

Not quite. By default, Linux doesn't allow a non-root application to request more than 256kB of receive space. What Transmission is requesting you to do is to allow it to allocate up to 4MB of buffer space.

Transmission will work fine with just the 256kB allowed by default, but you'll get packet loss if Transmission is unable to read data from the kernel's buffers in time, which might happen when there's heavy µTP traffic.

-- jch

comment:7 in reply to: ↑ 5 Changed 8 years ago by jch

1) If I can remember well, uTP is enabled by default and even preferred by clients(?)

By both µTorrent and Transmission, yes.

2) I bet most of Ubuntu users (and Mac as well?) will have a very little idea on "what this app mumbles about?". Not to mention that defaults will always prevail, no matter how many times you flood the log. I guess I'll be not first and not last person to discover that Transmission is slow, because it is (by default).

First, there's no evidence that the small-ish receive buffer actually harms performance. On an unloaded system, where Transmission is seldom scheduled out, it should not. If you have evidence that the larger buffers actually help on an unloaded system, please share your data, I'm interested.

Second, if really needed, then this should be tweaked by your friendly package manager when you install Transmission.

3) Other clients are working better without all these system-wide tricks, this implies there should be way for some better implementation of the same things. Correct me if I'm wrong, but, say, uTorrent does not requires anything like this, etc and able to achieve much better speeds under same conditions.

The µTorrent developers are smart, granted.

-- jch

comment:8 Changed 7 years ago by yozik04

I have spent some time to investigate this issue.

I am using version 2.42 on my DLink DNS-323 NAS Box.

  • When uTP is enabled I can not reach upload speeds above 25kb/s.
  • When it is disabled I can reach the maximum of 500kb/s.

During the test I was using my own local tracker(opentracker) with one seeder and one leecher.

I do confirm that uTP slows down upload drastically.

comment:9 Changed 7 years ago by cit

I did run some tests and maybe can bring new light on this problem

  • I can confirm that this problem still exists in transmission 2.50
  • I replaced third-party/libutp with the current version of libutp which is available at Github https://github.com/bittorrent/libutp: problem still exists
  • I started a file transfer with utp_recv and utp_send which are supplied with libutp and I can get the full speed with uTP

This means that libutp is not responsible for that problem. The problem must be somewhere in transmission. I also changed with the following line of code to the values from utp_send but without any luck:

libtransmission/peer-io.c:624

UTP_SetSockopt( utp_socket, SO_RCVBUF, UTP_READ_BUFFER_SIZE );

comment:10 Changed 7 years ago by ssiloti

I'm able to reproduce this on my test setup downloading between two Virtualbox VMs.

What I've found to be causing quite a bit of slowdown is the fact that UTP only writes data in bandwidthPulse. The lack of any on demand writing hurts performance on short-fat links where writing every 500ms is not enough to keep the send buffers full. Adding a call to tr_peerIoTryWrite with howmuch set to SIZE_MAX on UTP_STATE_WRITABLE improved transfer rates from ~150KB/s to ~4MB/s which is comparable to TCP on the same setup. tr_peerIoTryWrite should probably only be called if on demand IO has been enabled by tr_bandwidthAllocate but it's getting late. I'll come back with a patch tomorrow if no one beats me to it.

comment:11 Changed 7 years ago by jordan

ssiloti, sounds great! thanks for investigating this.

Changed 7 years ago by ssiloti

comment:12 Changed 7 years ago by cit

I can confirm that with this patch I get nearly the full speed in my network. Thank you very much - Great work!

-- cit

comment:13 Changed 7 years ago by reardon

  • Cc thomas_reardon@… added

comment:14 Changed 7 years ago by cfpp2p

Without patch and in my test environment: when transmission forced to upload via uTP only, upload rate was far less than forced download uTP only. With ssiloti's patch rates were identical. Patch seems to correct a slow uTP upload. Patch is good as per these tests.

comment:15 Changed 7 years ago by livings124

  • Milestone changed from None Set to 2.70

comment:16 Changed 7 years ago by livings124

Thanks! r13464

comment:17 Changed 7 years ago by jordan

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.