Add UDP configuration message for Mac OS

[jch]

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

[x190]

iMac:~ sn$ sysctl -a | fgrep tcp
net.inet.tcp.rfc1323: 1
net.inet.tcp.rfc1644: 0
net.inet.tcp.mssdflt: 512
net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.sendspace: 65536
net.inet.tcp.recvspace: 65536
net.inet.tcp.keepinit: 75000
net.inet.tcp.v6mssdflt: 1024
net.inet.tcp.log_in_vain: 3
net.inet.tcp.blackhole: 2
net.inet.tcp.delayed_ack: 3
net.inet.tcp.tcp_lq_overflow: 1
net.inet.tcp.drop_synfin: 1
net.inet.tcp.reass.maxsegments: 2048
net.inet.tcp.reass.cursegments: 0
net.inet.tcp.reass.overflows: 0
net.inet.tcp.slowlink_wsize: 8192
net.inet.tcp.maxseg_unacked: 8
net.inet.tcp.rfc3465: 1
net.inet.tcp.rfc3465_lim2: 1
net.inet.tcp.rexmt_thresh: 2
net.inet.tcp.path_mtu_discovery: 1
net.inet.tcp.slowstart_flightsize: 1
net.inet.tcp.local_slowstart_flightsize: 8
net.inet.tcp.newreno: 0
net.inet.tcp.tso: 1
net.inet.tcp.ecn_initiate_out: 0
net.inet.tcp.ecn_negotiate_in: 0
net.inet.tcp.packetchain: 50
net.inet.tcp.socket_unlocked_on_output: 1
net.inet.tcp.sack: 1
net.inet.tcp.sack_maxholes: 128
net.inet.tcp.sack_globalmaxholes: 65536
net.inet.tcp.sack_globalholes: 0
net.inet.tcp.minmss: 216
net.inet.tcp.minmssoverload: 0
net.inet.tcp.do_tcpdrain: 0
net.inet.tcp.pcbcount: 2
net.inet.tcp.icmp_may_rst: 1
net.inet.tcp.strict_rfc1948: 0
net.inet.tcp.isn_reseed_interval: 0
net.inet.tcp.background_io_enabled: 1
net.inet.tcp.rtt_min: 1
net.inet.tcp.randomize_ports: 0
net.inet.tcp.tcbhashsize: 4096
net.inet.tcp.background_io_trigger: 5
net.inet.tcp.msl: 15000
net.inet.tcp.always_keepalive: 0
net.inet.tcp.broken_peer_syn_rxmit_thres: 7
net.inet.tcp.pmtud_blackhole_detection: 1
net.inet.tcp.pmtud_blackhole_mss: 1200
net.inet.tcp.win_scale_factor: 3
net.inet.tcp.in_sw_cksum: 252
net.inet.tcp.in_sw_cksum_bytes: 10356
net.inet.tcp.out_sw_cksum: 0
net.inet.tcp.out_sw_cksum_bytes: 0
net.inet.tcp.sockthreshold: 64

iMac:~ sn$ sysctl -a | fgrep udp
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.udp.checksum: 1
net.inet.udp.maxdgram: 9216
net.inet.udp.recvspace: 42080
net.inet.udp.in_sw_cksum: 0
net.inet.udp.in_sw_cksum_bytes: 0
net.inet.udp.out_sw_cksum: 0
net.inet.udp.out_sw_cksum_bytes: 0
net.inet.udp.log_in_vain: 3
net.inet.udp.blackhole: 1
net.inet.udp.pcbcount: 35
net.inet.udp.randomize_ports: 1

iMac:~ sn$ sysctl -a | fgrep sockbuf
kern.ipc.maxsockbuf: 4194304
kern.ipc.sockbuf_waste_factor: 8

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

[jordan]

x190: does running that sysctl command make the error message go away, though?

[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

[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

[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:"

[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)

[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.

[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?

[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.

[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.

[jordan]

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.