Performance Tuning the Network Stack on macOS High Sierra 10.13 and Mojave 10.14

This is my third post on this topic. My previous posts have been viewed over 146,000 times. So, I guess a few people have found my analysis useful and worthwhile. Please refer to these previous posts for further explanation and detail on the specific settings beyond what I’ve included here.

• https://rolande.wordpress.com/2010/12/30/performance-tuning-the-network-stack-on-mac-osx-10-6/
• https://rolande.wordpress.com/2014/05/17/performance-tuning-the-network-stack-on-mac-os-x-part-2/

It seems that Apple keeps changing old default settings, removing options, and adding new parameters with each new OS release. So, I may be a little slow but I eventually get around to upgrading and sifting through the changes. The information in this article is targeted to the average home MacBook user and does not really address much of the high end power user needs like 10Gig networking. So, without further ado, here is what I have discovered so far with macOS Mojave 10.14 running on a MacBook Pro 15″ 2019.

It appears that the option to enable RFC1323 High Performance TCP Options is no longer an option and is now enabled as a default setting. This automatically adds 12 Bytes of overhead to the MSS. Apple is STILL defaulting the MSS to 512 Bytes! I am still recommending to set your MSS (net.inet.tcp.mssdflt) to 1448. Other than that, there are only a handful of other kernel options remaining that can help you get more out of your Internet connection.

Apple appears to be setting the MSL (net.inet.tcp.msl) Maximum Segment Life to 15000 or 15 seconds as a default. This is good for any Gigabit interface to prevent the TCP wrap issue. Apple is now defaulting the setting for Delayed ACK (net.inet.tcp.delayed_ack) to 3 which is for Auto-Detect. 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. Apple used to have an issue on higher speed interfaces but they may have overcome this problem.

In the comments on my previous post, a contributor noted that on interfaces above 1Gig (e.g. 10Gig), it appeared that the delayed_ack feature presented performance issues. The large majority of users will not be impacted by this behavior on 100Meg or 1Gig interfaces. If you experience any sort of connection hanging, you may want to disable this feature by setting it to 0.

You should set your TCP blackhole setting to a value of 2. This will prevent your Mac from sending RST packets for closed ports. This is a sort of stealth mechanism but also reduces unnecessary overhead. As a client machine, there is no reason you need to be friendly to remote systems.

The slowstart_flightsize parameter governs how fast your TCP stack can ramp up to using your full TCP window or link bandwidth outside of your local network. This number is a little more complicated to arrive at. It depends on you link speed and latency.  In order to more quickly overcome TCP slowstart, I have bumped this up quite a bit. This allows my system to use up to 10% of my bandwidth during TCP ramp up. I calculated this by figuring my Bandwidth-Delay Product and taking 10% of that value divided by the max MSS of 1448 bytes to get rough packet count. So, taking the line rate at 1000Mbps or 1000 x 10⁶ x 25 milliseconds or 0.025 seconds / 8 bits per byte / 1448 bytes per packet x 10%, I came up with roughly 215 packets. That is a pretty aggressive value. Arguably, I don’t really need to be consuming all of my link bandwidth when I have quite a few other people and devices also using my network. This is especially true at the moment during this home quarantine period where we have myself and my wife working from home on VPN and 4 kids all using Google classroom and Zoom and FaceTime and YouTube on a continual basis. So, I decided to use my best case latency, instead of my general average, as the basis for my calculation. This is anywhere from 4 to 7 milliseconds for services local to the DFW area. So, using the upper end at 7 milliseconds, I come up with about 60 packets.

The TCP sendspace and recvspace parameters control the maximum TCP window size the system will allow sending from the machine or receiving to the machine. This means how many packets can you send or receive before you have to wait for an acknowledgement or ACK packet from the receiver or before you send an ACK packet back to the sender. The less ACKs you have to wait for or send, the faster data will move on the wire. You will see less throughput oscillation and more consistency from TCP. Please refer to my previous posts for the explanation on how you can calculate this. I arrived at my value using my Bandwidth-Delay Product. I have a 1Gbps connection with an average round trip latency of about 25 milliseconds. That is equivalent to 25,000,000 bits or 3,125,000 Bytes on the wire during any 1 round trip interval. So, I chose 3125000 as my upper limit for both my sendspace and recvspace parameters. This requires my win_scale_factor to at least be set to 6 so that the counter is able to mathematically reach this value.

The default setting for auto scaling the receive and send buffers is artificially low based on the defaults macOS ships with. You will want to adjust those at a minimum to your maximum window size which in my case is 3125000.

Following are the specific settings I modified on my iMac running macOS 10.13.6 High Sierra. It is wired with a Gigabit ethernet connection and my Internet service is 1Gig bi-directional fiber. My local round trip network latency to AT&T is around 3 to 4 milliseconds. I can consistently hit Google service between 4 to 6 milliseconds. Outside of Dallas, I see round trip latency around 25 to 45 milliseconds on average.

net.inet.tcp.mssdflt=1448
net.inet.tcp.blackhole=2
net.inet.tcp.slowstart_flightsize=60
net.inet.tcp.sendspace=3125000
net.inet.tcp.recvspace=3125000
net.inet.tcp.win_scale_factor=6
net.inet.tcp.autorcvbufmax=3125000
net.inet.tcp.autosndbufmax=3125000