Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Getting intermittent pack loss on 10GbE M2 Studio ethernet port after coming out of power-saving mode. Taking out ethernet cable and plugging it back in fixes it until next time. But very annoying. Connected to Unifi 10GbE Flex XG.

Will have a look at debugging over the next week or two and let you know what fixes it, if anything.

View attachment 2248807
I'm on travels and will check a similar config when I get back. I have a USG-8 switch that has issues on 2 Mac Studios (first release and second release). I bought a Flex XG thinking that might fix it, but haven't had a chance to try it out.
 
Getting intermittent pack loss on 10GbE M2 Studio ethernet port after coming out of power-saving mode. Taking out ethernet cable and plugging it back in fixes it until next time. But very annoying. Connected to Unifi 10GbE Flex XG.

Will have a look at debugging over the next week or two and let you know what fixes it, if anything.

View attachment 2248807
I have Ubiquiti equipment too (same Flex XG) and I don’t have this issue. I used to get it when my Eero acted as the gateway. But now I use the Ubiquiti Dream Machine.

Also I replaced all my patch cables to Cat8 ones and it has helped. The patch cables I used before were a mess it seemed.
 
For the sake of closing this out for me... I resolved my persistent ongoing issues after trying all sorts of things. What finally fixed the problem was dumping my NetGear CAX80 router with its flawed 2.5GBE port and replacing it with a Motorola MT8733.. There are loads of people on the NetGear forums having problems with the same port on this router, all of them unacknowledged by NetGear. So I am done with using their routers after perhaps 20 years.
 
  • Like
Reactions: Ethosik
intresting on the upstream router being the cause. I have a UniFi USG. Cables replaced 4 times to mitigate it, no difference. Will see what happens if I restart the router during packet loss.
 
I'm wondering if switching to a CAT7 cable from my existing CAT6 might help my situation, along with making the Ethernet setting changes mentioned above.

I have no problems with general internet connection with my eero 6Plus router and Mac Studio. But when I use the company VPN, there is apparently plenty of ConnectionTimeouts and packet loss that it drops the connection to the server constantly - even when the Mac is sitting idle (but not sleeping). It was so bad that I yanked the eero 6Plus router and put the old eero Pro router back in place and have no issues at all.
 
Packet loss appears to have been fixed. To fix the packet loss I set the Studio ethernet port from auto-negotiation to manual 10GbE, and it hasn't occurred again since.
 
Just to confirm I have finally managed to check my M2 Max Studio with a Ubiquiti USW Flex XG which gives me a 10G port to connect to. This was after a variety of freezes with this machine and also a previous M1 based Studio.

So far the connection feels a lot more stable (no freezes to date), and the responsiveness on page loads in Safari seems a little faster.

Expensive way of fixing the issue, but worth it !
 
If anyone finds this topic here in July 2025, I was encountering the exact same issue with an M4 Max Mac Studio. High load would cause the Ethernet connection to drop and reconnect.

TL;DR: Solution was turning on Jumbo frames in macOS Ethernet settings. :)

What I did:

  • Cycle all power: switches, routers, the works.
  • Check all Ethernet connections of course, from the Studio all the way to my Fios ONT.
  • Reset the Mac's network settings. Flipped from auto Ethernet config to manual, back again, all the usual software steps.
  • Still having the issue. Hmm.
  • Replaced a bunch of cables; one of my runs had some tight turns and was an older but previously working cable, but figured better safe than sorry. This was boiling the ocean but I had intended to replace some cables anyway, so figured why not do it as part of troubleshooting.
  • Issue persists. Literally have never run into this problem before. Hmmmmm.

So I started running the amazing Packet Loss Test and keeping an eye on all my gear. Over a long test (120sec) I visually caught my switch unlink (lights out!) the connection to the Studio. It would drop, macOS would signal that Ethernet was disconnected, and a second later it would relink.

Fiddled with the switch. Tried another patch cable. Still the same problem.

Went back to macOS Ethernet settings, into hardware. Reset some stuff. On a whim, left Jumbo frames turned on—somewhere in the recesses of my brain from my sysadmin days was "Jumbo packets are good on high bandwidth low latency networks," which describes mine.

Fired up Packet Loss test again. Fingers crossed. 120sec later, everything was fine. Ran the test again about 10 times in a row, eyeballing the switch and the test simultaneously.

Problem totally solved.

I can't explain this at all, but sure enough, this worked for me. Give it a shot if you're finding your Studio's Ethernet is being dramatic.
 
Last edited:
jthelemur wrote:
"I started running the amazing Packet Loss Test"

What is this app (?) called Packet Loss Test, and where can I find it?
Or... is it a terminal command?
 
If anyone finds this topic here in July 2025, I was encountering the exact same issue with an M4 Max Mac Studio. High load would cause the Ethernet connection to drop and reconnect.

TL;DR: Solution was turning on Jumbo frames in macOS Ethernet settings. :)

What I did:

  • Cycle all power: switches, routers, the works.
  • Check all Ethernet connections of course, from the Studio all the way to my Fios ONT.
  • Reset the Mac's network settings. Flipped from auto Ethernet config to manual, back again, all the usual software steps.
  • Still having the issue. Hmm.
  • Replaced a bunch of cables; one of my runs had some tight turns and was an older but previously working cable, but figured better safe than sorry. This was boiling the ocean but I had intended to replace some cables anyway, so figured why not do it as part of troubleshooting.
  • Issue persists. Literally have never run into this problem before. Hmmmmm.

So I started running the amazing Packet Loss Test and keeping an eye on all my gear. Over a long test (120sec) I visually caught my switch unlink (lights out!) the connection to the Studio. It would drop, macOS would signal that Ethernet was disconnected, and a second later it would relink.

Fiddled with the switch. Tried another patch cable. Still the same problem.

Went back to macOS Ethernet settings, into hardware. Reset some stuff. On a whim, left Jumbo frames turned on—somewhere in the recesses of my brain from my sysadmin days was "Jumbo packets are good on high bandwidth low latency networks," which describes mine.

Fired up Packet Loss test again. Fingers crossed. 120sec later, everything was fine. Ran the test again about 10 times in a row, eyeballing the switch and the test simultaneously.

Problem totally solved.

I can't explain this at all, but sure enough, this worked for me. Give it a shot if you're finding your Studio's Ethernet is being dramatic.
I used jumbo frames for a while, but found some weird things occurring that I could not explain. For example, if jumbo frames are turned on, the menu for Xfinity.com and my daughter's school would not show. Turn them off, they show. Back on, no show. There must be an issue with how Ubiquiti UniFi routers translate things.
 
Amount of voodoo magic in this thread is astounding.

Folks, let me share with you some of my comments from a humble network engineer perspective. I hope at least some of you will find them useful, but I'm absolutely sure some of you will just ignore them. Also, please remember that outside of the networking realm, you may be indeed hitting MacOS bug(s) and that part I can't comment on.

So, let's turn off voodoo magic first:
  • jumbo frames should not have any impact on port stability; if enabling/disabling them in your case causes problems to go away, my guess is that a) your switch doesn't support 10GE port correctly (judging from what kind of hardware people use this is more probable) or b) there's a problem with your cabling or c) there's some setting somewhere else between your Mac and networking device causing it to fail; chances are, some combination of these or all of these three things happening at the same time based on what you did configure/reconfigure as well as what kind of cabling and networking gear you have;
  • anything that runs on 1GbE copper ethernet and above requires autonegotiation to be enabled (IEEE 802.3 clause 28); based on that, among other things, clocking is established and forcing it to manual will remove protections provided by the network interface card interface to your OS; what kind of protections? well, exactly those that allow for stable port operation, and lack of which ends up with observations like the ones in this thread - problems like "initially works but then doesn't", "it's not waking up", or "significant amount of drops but link is up";
  • you need Cat6A cabling for normal installation, especially if you're looking at cable runs close to maximum standard limit of 100 meters; you can run 10GbE on 20-30 meter cable runs using Cat6; you won't likely have any success even with good Cat5/5E cabling as it's not specc'ed up to the frequencies needed to transport anything above 2.5Gbps (that's why some of you report "it works sometimes at 2.5Gbps or 5Gbps but drops"); get yourself proper Cat6A patchcord between your switch port and your Mac, you already paid thousands of dollars for Mac Studio - 10 pack of good Monoprice 6A Etherent patchcords will set you back by whole 30 bucks and give you piece of mind;
  • make sure you use quality switch on the other side of connection, and that vendor supplies actual documentation that certifies it uses and supports all IEEE standards required to run proper 10GBase-T operation (10GbE for short here);
Please, avoid using (quoting Ivan Peplnjak): "Monte Carlo approach to device configuration: trying every combination of GUI-accessible features till one of them appears to be working. The Heisenbergian properties of this approach can be greatly enhanced by throwing random results of Google search at the problem.". Don't do it.

So, for 10GBase-T networking, treat this as a baseline:
  • get a good switch, meeting IEEE standards; I work with Cisco (as I work for Cisco), but decent Juniper, Arista or HPE switch should guarantee stability; anything else - consult your local networking guru; you may be doing voodoo magic because your switch was built for 55$ and sold to you at 2500$ to create illusion of value and quality;
  • get a good patchcord to connect it to your switch; if one side terminates as pluggable module (SFP+, typically the module itself is called "SFP-10G-TX" or similar, various vendors will call it using all kind of different things) you'll need to verify the module specification and maximum supported cable run; this is because pushing 10Gbps signal over copper is very power intensive and these SFP/SFP+ modules have very specific power budgets (to not cause overheating of the entire NIC or switch cage); that's why you'll find massive radiators on 10GbE copper NIC cards from Intel for example; SFP doesn't have a lot of space, therefore most copper SFP+ have distance limits of 25-30m even with Cat6A cabling(!) - again, check both switch docs for SFP support, and SFP specs to understand how long the cable can be;
  • run it as autonegotiated port;
  • you may choose to disable power-efficiency as this indeed may cause all kinds of interesting behaviors and hit corner cases depending on (again) switch ports and switch configuration;
  • you may also disable ABV/AEV - those are special IEEE protocols to bridge audio frames, for applications that require ultra low latency and minimized jitter; if you're hitting problems - getting rid of complex subsystems may not be worst idea for troubleshooting; in general though, it should work without problem
For those of you that are curious - I run my Mac Studio connected over ~30 meter run of Cat6A to a "multigig" port of Catalyst 9300X. I didn't touch the NIC settings, it works with everything enabled (including energy efficiency protocol), but I know my network is (likely) not your network. Yes, there are cheaper alternatives, but watch out for what you're paying for because YMMV. If I can point you somewhere - go through Patrick Kennedy's ServeTheHome site for some ideas about cheaper but capable networking gear.

Good luck!
 
Last edited:
  • Like
Reactions: b17777 and Daydog
I used jumbo frames for a while, but found some weird things occurring that I could not explain. For example, if jumbo frames are turned on, the menu for Xfinity.com and my daughter's school would not show. Turn them off, they show. Back on, no show. There must be an issue with how Ubiquiti UniFi routers translate things.
Jumbo frames require properly working TCP MSS (Maximum Segment Size) negotiation. It's advertised in first packet (TCP SYN), but still surprisingly a lot of equipment will break it one way or another. Also, if you enable jumbo frames, you should adjust MTU (Maximum Transmission Unit) in given Ethernet segment (typically VLAN that your device resides in). And remember, that UDP doesn't have any way to detect proper payload size and therefore typically UDP breaks first in case of mismatch.

Check if your Ubiquity has anything to set/adjust MSS. In Cisco world this is handled with `ip tcp adjust-mss X` where X is number of bytes to use for MSS.

Then, make sure your switch has MTU adjusted for the segment your station resides in.

Finally, jumbo frames make sense only if you have other devices that can benefit from increased payload size - like NAS/DAS or another Mac for example. If you're doing this on one system only, it's waste of time.
 
Jumbo frames require properly working TCP MSS (Maximum Segment Size) negotiation. It's advertised in first packet (TCP SYN), but still surprisingly a lot of equipment will break it one way or another. Also, if you enable jumbo frames, you should adjust MTU (Maximum Transmission Unit) in given Ethernet segment (typically VLAN that your device resides in). And remember, that UDP doesn't have any way to detect proper payload size and therefore typically UDP breaks first in case of mismatch.

Check if your Ubiquity has anything to set/adjust MSS. In Cisco world this is handled with `ip tcp adjust-mss X` where X is number of bytes to use for MSS.

Then, make sure your switch has MTU adjusted for the segment your station resides in.

Finally, jumbo frames make sense only if you have other devices that can benefit from increased payload size - like NAS/DAS or another Mac for example. If you're doing this on one system only, it's waste of time.
Did it to connect NAS to mine and my wife's computers. Mainly my wife's computer since she deals with video and photos stored on the NAS.

Jumbo frames were enabled on all switches.

There's a way to set the MTU manually, but it really wasn't worth the effort. The amount gained from it wasn't that much (10G network).
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.