FS#39035 - [transmission-cli] increase default net.core.{r,w}mem_max.

Attached to Project: Arch Linux
Opened by René Herman (rene) - Monday, 24 February 2014, 21:08 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Monday, 03 August 2015, 09:03 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Tom Gundersen (tomegun)
Anatol Pomozov (anatolik)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Transmission requests larger UDP send and recv buffers than linux by default allows and notes this in its log:

Failed to set receive buffer: requested 4194304, got 262142
Failed to set send buffer: requested 1048576, got 262142

Although I knew this, I only noticed it again today after a long time of having forgotten to "fix" this on a newly installed system when browsing the transmission log. It's debatable whether or not the larger sizes should actually be all that helpful (on not exceedingly fast and busy links, at least) and as such, it's certainly not a package bug -- but I thought I'd hereby ask the maintainer if (s)he feels that adding:

=== /usr/lib/sysctl.d/00-transmission.conf ===
net.core.rmem_max=4194304
net.core.wmem_max=1048576
===

to the transmission package would be helpful. Transmission does request those larger sizes, and I after all know not of reasons to NOT allow them, so, perhaps, ...

NB: If yes, the install script should also run "sysctl -p 00-transmission.conf" to adjust the values for the current boot as well.
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Monday, 03 August 2015, 09:03 GMT
Reason for closing:  Won't fix
Comment by René Herman (rene) - Monday, 24 February 2014, 21:15 GMT
Crap, sorry, forgot to put in an actual title on this post/request; don't believe I can fix this now. If anyone can:

[transmission] increase default net.core.{r,w}mem_max.

would probably be good...
Comment by Jan de Groot (JGC) - Tuesday, 25 February 2014, 11:41 GMT
So by installing transmission without ever using it, the user will get new default buffer settings applied to his system? Doesn't make sense to me.

Comment by Dave Reisner (falconindy) - Tuesday, 25 February 2014, 13:03 GMT
I don't like it either but notice that this is only changing the hard limit, not the default size. The net effect is zero unless someone call setsockopt to take advantage of the larger buffer sizes
Comment by Jan de Groot (JGC) - Tuesday, 25 February 2014, 13:42 GMT
If the hard limit is changed by just installing transmission, why is there a lower hard limit in the first place?
Comment by Dave Reisner (falconindy) - Tuesday, 25 February 2014, 13:58 GMT
To curtail potential memory usage, I suppose. Every socket has its own buffer capable of growing up to the max size specified.
Comment by Daniel Micay (thestinger) - Tuesday, 25 February 2014, 14:04 GMT
What do other distributions do? Are they just using higher hard limits by default? It seems like it would be completely fine to increase the hard limit as long as the automatic scaling is untouched.
Comment by Jan de Groot (JGC) - Tuesday, 25 February 2014, 14:23 GMT
I checked Debian, they don't change these defaults just for transmission either. On my Debian Squeeze system with 3.2 kernel the defaults for these settings is 131071. Fedora doesn't change the defaults by installing transmission either.

I don't have a problem with transmission taking 4MB send/receive buffers, but the fact that it allows any program to take 4MB send/receive buffers scares me.

(BTW: large buffers are bad. There's a reason why recent kernels started killing network buffers).
Comment by Daniel Micay (thestinger) - Tuesday, 25 February 2014, 14:31 GMT
True, perhaps it's worth reporting this as a transmission bug. The large buffers are not just a sacrifice of latency for throughput but break down congestion control (although I use tcp_lp anyway).
Comment by René Herman (rene) - Tuesday, 25 February 2014, 15:23 GMT
Fair enough; I'll keep it local then.
Comment by Doug Newgard (Scimmia) - Sunday, 02 August 2015, 17:00 GMT
Someone needs to make the call here, should we keep this ticket open?

Loading...