Apple has been lying to me for years
Dramatic headline isn’t it? Sure it’s probably clickbait but it’s the truth none the less. I’m talking about the application Activity Monitor.
Years ago I got my hands on a switch that supported LAG (Link Aggregate), the ability to merge two ethernet ports together and get a considerable bandwidth boost. Not all LAG/LACP are the same and implementation standards even vary between manufacturers so some might use LAG as failover, others to get more bandwidth. My goal was of course, more bandwidth.
And sure enough, as soon as I set it up, Activity monitor showed double the speed on LAN data transfers to and from the local server, which was also set up on a LAG. For years I have worked under the assumption that LAG works and doubles my bandwidth. Many have told me it doesn’t work and I had the numbers and screenshots to prove them wrong.
From my switch manual, for example:
Every Mac on my network is set up with a LAG and according to Activity Monitor, it has been working as it should. File transfers *felt* faster too but maybe that was all a trick of the mind.
So how did I end up at the conclusion Activity Monitor has been lying to me all along? I started digging into this while I was speed testing my new Xserve RAID over the LAN, speeds were disappointing.
Many tests and a week later, I did a few simple tests to show you what’s going on. The test is simple; use a disk speed test utility on a network share and capture the utility and activity monitor side by side. Do this for single port ethernet as well as a LAG setup. Utilities I used were:
All these utilities tested within a few MB/sec from eachother so the screenshots will only show AJA System Test Lite as it fit better on my screen.
First up, my 2009 17″ MacBook Pro with SSD (single ethernet port).
As you can see, Activity Monitor is pretty close to the speeds AJA reports.
Moving on to my 2009 Mac Pro with 4x1TB RAID0 (single ethernet port).
Here, Activity Monitor oversold it a little but close enough. Then I put the Mac Pro on a LAG and tested again (dual ethernet ports).
And here is why I believed LAG/LACP was working for the longest time; Activity Monitor doubles the numbers! It also adds a few MB/sec on top of that for whatever reason as it did before in single ethernet port tests. The actual data transfers are not faster at all. To confirm I ran the same tests on my 2012 Mac Pro which has Mojave and SSD’s installed (single ethernet port).
Again, Activity monitor adds a dozen MB/sec on top but results are close to actual speed. Now I set up a LAG and ran the tests again (dual ethernet ports).
And the fake news returns.
I tested this on G5, Mac Pro and Mac mini (1 ethernet and 1 thunderbolt to ethernet adapter for the LAG). The OS versions I tested were 10.4.11 – 10.14.2. Activity Monitor pulls the same stunt every time.
I try not to curse on my blog but, what the fuck Apple??!
People spend money on switches, extra cable etc. to set up LAG and it turns out not to work at all? Can Mac OS X / macOS even properly support LAG? Of course one could say I should have done this test a decade ago when I first started using LAG, and you’d be right. I trusted Apple not to screw me over and while that was an acceptable mindset in 2008, I have of course come to my senses on that so should have done these tests later on. I’m both glad I did these tests now and found out the truth, as well as sad that LAG turns out to be a complete waste of time on macOS.
Oh and the same goes for the reported speeds in the “Disk” tab of Activity Monitor, it shows you double the actual read/write speeds. At least while a LAG is active, I have not tested the disk speeds without a LAG active.
If anyone out there reading this can shed some light on the state of LAG/LACP and macOS or maybe test the same switch on both Mac and PC to see if Windows can pull it off, I’d love to hear about it.
A big thank you to my Patreon supporters for making this and future content possible!
- Michael Stanhope
- Greg Thompson
- Greg Hrutkay of Hrutkay Mods
9 thoughts on “Apple has been lying to me for years”
Interesting article. I am going to test when I get home from vacation.
LAG provides double the bandwidth when copying multiple files. I.E. File A goes down Ethernet Port A, File B goes down Ethernet Port B.
If you are only transferring a single file, you won’t see any increase in bandwidth.
This is common across ALL LAG connections, it’s not an Apple only thing.
I tested this and even when copying several files (same session or different sessions) the speed tops out at 75-ish MB/sec. Exact same performance as copying a single file. Copying one file to while copying another file from a share results in 50MB/sec up and 40MB/sec down, it cuts the bandwidth in half.
As explained in the below page, you’re limited to the bandwidth of a single interface when communicating with one device. If two of your machines talk to your server both can transfer at a gigabit at the same time.
https://www.netgate.com/docs/pfsense/interfaces/lagg-interfaces.html#lagg-bandwidth at the same time
The problem is that LACP with a single source and destination will not increase your bandwidth as a single link in that trunk will be used for the traffic. Alternatives are to not use LACP but use multipath SMB (badly implemented for OSX) or NFS4.1 which supports multichannel NFS. However, even Big Sur still only supports up to NFS 4.0 at this point in time.
GJ hit the nail square on. Single source will not take advantage of the second connection as LACP uses a hashing algorithm to determine the path. Now, if you were using virtualization (VMware, containers, etc – each with a unique MAC address), the hashing would balance the load across both links. Your MAC wasn’t lying to you. It was doing exactly what LACP was designed to do.
When Activity Monitor tells me I’m transferring at 261MB/sec while I’m actually transferring at 81MB/sec, I’d call that a lie.
Just found this post and I ran into the same issue with activity monitor. It is reporting double the actual transfer when a link aggregate is active. I am also not able to ever get the aggregate link to my mac to go over the (real) bandwidth of a single link ever but my linux machines have no problem doing that whatsoever. Using multiple iperf3 sources and server instances to test this. Apple is clearly lying to us and I am starting to suspect that the aggregate link simply doesn’t work as it should. Not surprising as I am sure very few people use this on Macs but still!
I have also been struggling to make a LAG work in my network with two Macs connected to a QNAP 10GbE switch. Bottom line: I’ve tested two different switches and my network speeds get SLOWER when I implement LAG. I cannot get to the bottom of why. The switch and the network cards all support Link Aggregation. I’m using Cat 8 cables across the board. I feel like there is something wrong on the Mac OS side when creating a virtual bonded port. Either way it was a waste of money it seems that I got the hardware to try and make this work. Very disappointed.