System Hackery

Sometimes I find ways to make life easier for my coworkers, things they couldn’t possibly understand but would benefit them anyways. A few weeks ago I discovered a series of system level adjustments to the TCP/IP stack which I thought would benefit everyone. These adjustments, just in case anyone was curious and technically so are here:

/etc/sysctl.conf


kern.ipc.maxsockbuf=4194304
kern.ipc.somaxconn=512
kern.ipc.maxsockets=2048
kern.ipc.nmbclusters=2048
net.inet.tcp.rfc1323=1
net.inet.tcp.win_scale_factor=3
net.inet.tcp.sockthreshold=16
net.inet.tcp.sendspace=262144
net.inet.tcp.recvspace=262144
net.inet.tcp.mssdflt=1500
net.inet.tcp.msl=15000
net.inet.tcp.always_keepalive=0
net.inet.tcp.delayed_ack=1
net.inet.tcp.slowstart_flightsize=4
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.icmplim=50

/etc/nsmb.conf


[default]
streams=no
minauth=none
soft=yes
notify_off=yes
port445=no_netbios

I found these files online in various sites and the ultimate goal was to find any way to make the networking work better for clients on their iMacs. Most of these settings make sense if you are using a plain Ethernet system like we are here at Western, most specifically the mssdflt setting at 1500. One setting that I think was causing some issues was net.inet.tcp.delayed_ack. This setting covers how the systems handle ACK packets in TCP/IP communications. Back in the 80’s there was a dispute on how TCP/IP should function and there has been confusion and splits between two camps ever since, and this setting causes issues all depending on which number you set it to, 0 through 3. Apple sets this feature by default to 3, and I had this turned to 0 for many workstations and then I started noticing people having problems accessing SupportPress reliably. Perhaps I was overzealous in the 0 setting, so then the question becomes, how to change the setting without upsetting people?

Of course, ARD to the rescue. I created a new list of computers at work, removed the obvious ones that shouldn’t be touched such as the primary file server and such, and for the rest I copied these two files to the client workstations. Alas, these changes don’t work unless you can reboot the stations. I was able to reboot remotely several unoccupied stations but that wasn’t a real solution. I need to cover all my bases, not only change the system so that the new settings are permanent over reboot, but that they take effect now instead of later. I was on the edge of sending out an email to the group asking them to please reboot their computers during lunch and then it struck me, why not simply ship out the adjustment over ARD? ARD can send Unix commands to connected workstations and it can masquerade as root, so, why not?

The command to find out what this setting has is:

sysctl -a|grep delayed_ack

The command to make a change while the user is online is:

sysctl -w net.inet.tcp.delayed_ack=1

The users have no idea I’m mucking about underneath their systems, way down in the BSD bits, all from my office, over the wire, with them logged in doing whatever it is that they are doing. Now all the workstations have this change effective immediately and when they reboot they’ll get this change applied automatically as well.

I will have to sit back and see if 1 is indeed the setting that will help. We shall see.

One thought on “System Hackery

  1. I would recommend you set net.inet.tcp.delayed_ack=3. Allowing delayed ACKs could cause pauses at the tail end of data transfers and used to be a known problem for Macs. This was due to a known poor interaction with the Nagle algorithm in the TCP stack when dealing with slow start and congestion control. Similar to you, I previously had recommended disabling this feature completely by setting it to “0″. I have since learned that Apple has updated the behavior of Delayed ACK to resolve this problem. Since the release of OSX 10.5 Leopard, Apple integrated support for Greg Minshall’s “Proposed Modification to Nagle’s Algorithm” into the Delayed ACK feature. I have now reverted this setting back to the default and enabled this feature in auto-detect mode by setting the value to “3″. This effectively enables the Nagle algorithm but prevents the unacknowledged runt packet problem causing an ACK deadlock which can unnecessarily pause transfers and cause significant delays.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.