Opened 12 years ago
Closed 12 years ago
#4207 closed Enhancement (invalid)
Add UDP configuration message for Mac OS
Reported by: | jch | Owned by: | |
---|---|---|---|
Priority: | High | Milestone: | None Set |
Component: | Transmission | Version: | 2.22+ |
Severity: | Minor | Keywords: | mac udp utp |
Cc: |
Description
The messages in tr-udp.c around line 77 only give advice on fixing the issue on Linux. It would be great to add a Mac OS X version.
I believe that the right sysctl on FreeBSD and Mac OS X is kern.ipc.maxsockbuf. It would be great if somebody could check that running
sysctl -w kern.ipc.maxsockbuf=4194304
makes the message go away, and put the right recipe in a message in tr-udp.c.
Milestoning for 2.30, since it's just a simple change in a debugging message. Jordan, please yell if you disagree.
--jch
Change History (11)
comment:1 Changed 12 years ago by x190
comment:2 follow-up: ↓ 6 Changed 12 years ago by jordan
x190: does running that sysctl command make the error message go away, though?
comment:3 follow-up: ↓ 5 Changed 12 years ago by jch
kern.ipc.maxsockbuf: 4194304
Interesting. So that means that the warning does not trigger on Mac OS X by default, right?
Can you please check your Transmission logs for the message "Failed to set receive buffer", and confirm that it is not there?
--jch
comment:4 Changed 12 years ago by sharpshot_uk
I see no such error message in T's debug log on OS X.
The only messages I see regarding a buffer are:
SO_SNDBUF size is 131070 SO_RCVBUF size is 262140
comment:5 in reply to: ↑ 3 Changed 12 years ago by x190
Replying to jch:
kern.ipc.maxsockbuf: 4194304
Interesting. So that means that the warning does not trigger on Mac OS X by default, right?
Can you please check your Transmission logs for the message "Failed to set receive buffer", and confirm that it is not there?
--jch
The warning does not trigger on the send side as your only limit appears to be the one set by kern.ipc.maxsockbuf: 4194304. However, it does trigger on the receive side as you are limited by net.inet.udp.recvspace: 42080 (see list above).
https://trac.transmissionbt.com/ticket/2338#comment:74
2011-02-17 23:11:44 -0700 tr-udp.c:72 [Error] UDP: Failed to set receive buffer: requested 4194304, got 42080
I'm going to do more research about the possibility of messing with net.inet.udp.recvspace: but, in any case, 99.9% of Mac Client users will not want to change system settings like this so there's likely no need to offer suggestions on what to change.
SL 10.6.7
EDIT:
I guess it could be increased somewhat. Suggest something a fair bit less than 4MB as kern.ipc.maxsockbuf: 4194304 is a total limit?
http://www.unbound.net/pipermail/unbound-users/2009-September/000804.html
"FreeBSD" "The default (net.inet.udp.recvspace) is 42080, I've gradually increased that to 256MB (I would say, it's insanely large) in the hope that it helps unbound get the packets, which arrive during it does *something*. I could get some improvement with this, there are even some periods, where the success rate was 100%, but it' still not perfect:"
comment:6 in reply to: ↑ 2 ; follow-up: ↓ 9 Changed 12 years ago by x190
Replying to jordan:
x190: does running that sysctl command make the error message go away, though?
The default setting already is kern.ipc.maxsockbuf=4194304, however, net.inet.udp.recvspace: 42080 sets the limit.
Fix for OSX. Tested on r12380.
trunk/libtransmission/tr-udp.c - Line 39 #define RECV_BUFFER_SIZE (4 * 1024 * 1024) + Line 39 #define RECV_BUFFER_SIZE (42080)
comment:7 follow-up: ↓ 8 Changed 12 years ago by jordan
That's still two orders of magnitude smaller than the previous value though. IMO that's not so much a fix, as it is something that makes the warning go away :)
However, I agree that it's unlikely that many Mac users will want to poke around with sysctl. So, a couple of thoughts:
- We still should have a comparable error message as suggested by Juliusz at the top of this ticket.
- Maybe we should have the _BUFFER_SIZE macros vary from platform to platform?
- Maybe we should try more than two different buffer sizes, since a value larger than SMALL_BUFFER_SIZE may be possible even if SEND_BUFFER_SIZE or RECV_BUFFER_SIZE isn't possible.
comment:8 in reply to: ↑ 7 Changed 12 years ago by x190
Replying to jordan:
That's still two orders of magnitude smaller than the previous value though. IMO that's not so much a fix, as it is something that makes the warning go away :)
However, I agree that it's unlikely that many Mac users will want to poke around with sysctl. So, a couple of thoughts:
- We still should have a comparable error message as suggested by Juliusz at the top of this ticket.
In my completely amateur but enjoy learning opinion, the current message is misleading. It suggests that setsockopt failed when in fact getsockopt says it got the max possible? If you want to add a sysctl -w message then the value to change would be net.inet.udp.recvspace: 42080. Proceed with caution! Don't forget the slow death syndrome which recommends moving these values in the opposite direction on the TCP side. :)
- Maybe we should have the _BUFFER_SIZE macros vary from platform to platform?
Yes, at least for OSX, IMO it would be best to work with system defaults.
- Maybe we should try more than two different buffer sizes, since a value larger than SMALL_BUFFER_SIZE may be possible even if SEND_BUFFER_SIZE or RECV_BUFFER_SIZE isn't possible.
I tried setting SMALL_BUFFER_SIZE to 42080 but that didn't help because SEND_BUFFER_SIZE tests to true regardless?
comment:9 in reply to: ↑ 6 Changed 12 years ago by x190
Replying to x190:
Replying to jordan:
x190: does running that sysctl command make the error message go away, though?
The default setting already is kern.ipc.maxsockbuf=4194304, however, net.inet.udp.recvspace: 42080 sets the limit.
Fix for OSX. Tested on r12380.
trunk/libtransmission/tr-udp.c - Line 39 #define RECV_BUFFER_SIZE (4 * 1024 * 1024) + Line 39 #define RECV_BUFFER_SIZE (42080)
Try this:
- Line 39 #define RECV_BUFFER_SIZE (4 * 1024 * 1024) + Line 39 #define RECV_BUFFER_SIZE (1 * 1024 * 1024)
worksforme! Seems you have to honor kern.ipc.maxsockbuf=4194304 as a total for all socket buffers or SO_RCVBUF/SNDBUF will only give you the default amount. So you need to ask yourself what the minimum buffer size is that you could live with. TCP socket buffers need to be considered here as well.
2011-04-29 03:24:25 -0600 fdlimit.c:644 [Debug] Transmission: SO_SNDBUF size is 131070 2011-04-29 03:24:25 -0600 fdlimit.c:646 [Debug] Transmission: SO_RCVBUF size is 262140
Jordan: You're only going to get 128K (SND+RCV) here for the first 64 sockets anyway and then the default remains at 128K. Bumping up buffer size (fdlimit.c:644/646) *3 is probably only going to contribute to system freeze as allocated memory is overshot.
EDIT: Will build with no error message up to 3 * 1024 * 1024 for RECV_BUFFER_SIZE and 1 * 1024 * 1024 for SEND_BUFFER_SIZE. If you insist on asking for 4 * 1024 * 1024 for RECV you will only get 42080.
OSX and Free BSD defaults.
comment:10 Changed 12 years ago by sharpshot_uk
I am now seeing:
"Failed to set receive buffer: No buffer space available" "Failed to set receive buffer: Requested 4194304, got 42080"
OSX 10.6.7 2.30b4 (12414)
Edit: This only occurs with uTP enabled.
comment:11 Changed 12 years ago by jordan
- Milestone changed from 2.30 to None Set
- Resolution set to invalid
- Status changed from new to closed
TI have strong doubts about how useful this ticket is. I doubt many (any?) users on OS X will act upon a "please run sysctl" suggestion in the message log, and this ticket seems to have stalled, so I'm closing this ticket.
net.inet.tcp.sendspace: + net.inet.tcp.recvspace: should not exceed kern.ipc.maxsockbuf: 4194304.
All settings above are default iMac 10.6.7
http://www.psc.edu/networking/projects/tcptune/#MacOS http://www.macgeekery.com/tips/configuration/mac_os_x_network_tuning_guide_revisited