I have one of these, but, with the 10G network option and never saw this issue.
Have to say I'm loving that little Mac mini. It was relatively cheap, it's absurdly fast, it's completely silent, it sits mounted to my wall behind my monitors.
I want to tell you I have a compelling reason why I have 10G at my house but, really, I don't have one.
There are some advantages besides speed though. Because it's DWDM FTTH (no PON, no DOCSIS, etc) I have 0 local congestion/issues and supreme reliability and a static IP. I don't do it for the speed.
According to many commenters in the linked thread, it's fixed in MacOS 13.2.1. Not great that it happened at all, but good to see that it was a software issue.
And, if it's something that's worked around in software (meaning, it was a hardware issue), that might have issues for things like Asahi Linux, which probably won't have that workaround in place.
Arguably it would impact the support for other OSes, especially alternative ones who'd need to reverse engineer the workaround and/or write their own to get the network stack working.
It could also fall apart the day Apple decides this machine is not supported anymore, and their next OS won't have the correct drivers anymore. It's their prerogative, but will sure suck for the machine owners.
PING fritz.box (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=11.845 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=24.287 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.120 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.630 ms
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.801 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.139 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.772 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.784 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.674 ms
The above suggestion fixes it, hopefully permanently:
settings->network-><ethernet interface>->details->hardware "change anything, safe and undo"
"So, folks -- I'm fairly sure this is a software issue.
If you go to settings->network-><ethernet interface>->details->hardware and then change "Configure" to "manual", THEN change ANY setting (I turned off ABV/EAP mode), save/exit and then go in and change it back; the packet loss seems to stop. (I also tried changing duplex to 'flow control' and back again, just incase it helps anyone)
I'm guessing the auto configuration has gotten something wrong and persisted it somehow. Try it out!
Really glad it's helping some people. I'm bummed because it doesn't seem to be helping me, which makes me think there's some device on my network that isn't playing well with the mac mini.
It would be helpful if someone would be willing to perform a packet capture while experiencing and testing this problem. I’d be more than happy to analyse further.
We should see the right number of valid ICMP packets put on the wire and whatever response we get back will be telling
Tell me what tcpdump one-liner magic you’d like and I’d be happy to provide a dump for you. I seem to be getting anywhere between 3% and 6% packet loss on my home network, pinging my server that is separated by about 6 feet of cat6 and a switch.
I had this issue earlier, it’s something to do with the combination of the Ethernet port on the mini and my particular switch. I swapped in another switch and it has worked flawlessly so far.
I was just thinking about getting the entry model M2 Mini as essentially just a build server so that I could build apps in a cross-platform framework and then just use Apple's walled garden to xcode signing. But I'll probably buy the prior gen if the non-Pro M2's also have buddy NICs.
Have to say I'm loving that little Mac mini. It was relatively cheap, it's absurdly fast, it's completely silent, it sits mounted to my wall behind my monitors.