Posted by: rolande | April 16, 2020

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

macOS Mojave 10.14This 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.

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




  1. […] This is my second post on performance tuning the OSX network stack. My previous post on this topic has gotten over 55,000 views and generated quite a bit of feedback and questions. This updated post is intended to address performance tuning the IP stack on OSX Mavericks and, hopefully, eliminate some of the confusion around many of the caveats and options, as this is a fairly complex topic. Much of this configuration and the settings are backwards compatible to previous OSX releases. However, please refer to my original post for the gory details and caveats related to previous OSX releases. You can also find my latest updates in my most recent post here. […]


  2. […] There is a decent amount of documentation out there that details all of the tunable parameters on the Mac OSX IP stack. However, most of these documents either provide basic suggestions without much background on a particular setting or they discuss some of the implications of changing certain parameters but don’t give you very solid guidance or recommendations on the best configuration in a particular scenario. Many of the parameters are dependent upon others. So, the configuration should be addressed with that in mind. This document applies to OSX 10.5 Leopard, 10.6 Snow Leopard, 10.7 Lion, and 10.8 Mountain Lion. Updates for 10.9 Mavericks are mostly minor. Here is a link to my latest post on performance tuning the network stack on OSX Mavericks 10.9. You can also find my latest updates for High Sierra and Mojave in my most recent post here. […]


  3. Hi Scott,
    does your tweaks apply system wide or is only strictly on the macbook’s wifi adapter?

    i have a couple of older macbooks with bad wifi card, hence ive gotten them external usb network adapters [ Dlink dw-192 ]

    does the foremeationed tweaks apply to universal usb network wireless adapter as well ?

    sincere regards/ J


    • Jen, these settings apply to the entire system TCP/IP stack regardless of the interface you are using.


      • Thanks Rolande!

        apologies for the very fundamentals of the question, my sincere thanks for pointing that out.

        Was worried if there’s additional tweaks required for external Wifi devices attached.

        BTW, would there be similar tweaks or settings adjustable within the iPad devices ?

        my sincere thanks !


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: