net.inet.tcp.recvspace and net.inet.tcp.sendspace control how much buffer space is allotted per socket connection, per direction. This is how much data the kernel will cache on a socket while the application chews on it. For data streams over a slow link (even 10Mb enet) this won’t matter as the processor can keep up rather well. On really fast links like gigabit, this is essential. This setting defaults to 32K each way but moving that higher lets the system get more data cached and ready for your system if it falls behind the network traffic. As a test, I rose this to 250KB for each direction on my local machine and another on my local gigabit network. Transfers went from 12MB/s to 25MB/s. Thinking I could get more, I then transferred data from both hard drives on the remote machine. Sure enough, the remote hard drive was the limiting factor and it jumped to 35MB/s. Just be very sure to update kern.ipc.maxsockbuf to match the total of both settings before changing these settings, especially in sysctl.conf. If you do not, then the kernel will attempt to allocate the buffer space for the two buffers and run out of space, preventing essential services like NetInfo from making a loopback connection and preventing startup and/or login.net.inet.tcp.mssdflt sets the default Maximum Segment Size, or the largest that the system will set the data portion of a TCP packet to. By default, many BSD-derivatives will set this to 512 bytes. Bad. Ethernet supports a frame size of 1,500 bytes on links up to 100 Mb or 9,000 bytes on 1000Mb links so if either is what you’re connected to then up this bad boy to the size of your frame minus the size of a TCP header and options (60 bytes). For 10/100Mb links, set it to 1,440; for 1000Mb links that have been explicitly set to use jumbo frames on all participating computers, set it to 8940. Remember: if you set your frames larger than the frames your router allows (on a large LAN) then it could fragment the packet when re-sending or outright crash, and either would suck. If you fail to calculate this correctly and it goes over the size of the hardware frame, then you’ll be fragmenting every non-trivial packet you send, slowing down your network. Be careful. net.inet.tcp.sockthreshold sets the number of open sockets needed for the system to actually obey your sendspace and recvspace marks. If the number of open sockets is below this number then the buffers are set to 64K, regardless of what you’ve set them to. This means that the system allocates 64K of buffer space to each socket connection direction, or 128K total, until you get to 256 open sockets, at which point they’re set to 32K (the default send/recvspace values). Set to 0 to disable and always use your custom sizes (not really a good idea). kern.ipc.somaxconn controls the size of the connection listening queue and typically only needs to be adjusted in high-performance server environments. The default value of 128 is more than adequate for a home/work machine and most workgroup servers. If, however, you are running a high-volume server and connections are getting refused at a TCP level, then you want to increase this. This is a very tweakable setting in such a case. Too high and you’ll get resource problems as it tries to notify a server of a large number of connections and many will remain pending, and too low and you’ll get refused connections. Source: Adam Knight