Mac mini experiencing slow network speeds on iPV4

dtdionne wrote:

I have a very similar problem with an OSX VM. It's just one of many VM's, linux and windows and they all work wonderfully. But the Sonoma vm has unusable ipv4 upload speed locally, to another VM. It can download from that very same vm fine. I scp big tarballs too and from the Mac and the linux web server...or that was the goal. But scp from the Mac to rhel9 either stalls or goes kb/s.

I disabled ipv6 but that didn't help. I run ipv4 locally. It's a deal breaker the way it is.

I watched the speedtest with Wireshark and it was indeed using ipv4 and upload was fine. This is wildly irritating.

Doing an scp I see a lot of dup ack's and retransmissions, and doubt that's good.

Problems involving VM guests add a whole new pile of complexity to these discussions, as this involves a whole virtual network existing within the VM, and those networks can be configured in all sorts of different ways, with different features, and different requirements and restrictions.

And no, duplicate acks and retransmissions are not good; something is probably re-ordering the network traffic, or routing is wonky.

Sorry, but I still need a few more bits of information in order to help you:

• I still need to know the exact model of your Mac mini.
• I still need to know if you connect your mini to your Asus by Ethernet or by wireless.
• Have you run any speed tests directly between your mini and router, or between your mini and any other client on your local network? Using a tool like iPerf?

Using a "speed test" tool, like Ookla does provide you with an end-to-end data transfer speed results, but it doesn't tell you where the bottleneck actually is.

I'm curious why the impact is primarily with IPv4. That protocol is stll the dominant one used for both local network and Internet communications.

FWIW, I have a 2023 M2 Pro Mac mini and a Synology DS916+ NAS. However, I do not have this Asus router (my local network is a Ubiquiti UniFi-based ecosystem), and my Internet service is still DSL. I should be able to at least provide statistics for my local network for comparison. Currently I use Ethernet for all the connections between my mini, NAS, & gateway router. Those connections all have 1 Gbps bandwidth, and average approx. 950-975 Mbps data rates. Streaming audio, or even, HD video from my NAS to the mini does not exhibit any stuttering. I primarily use IPv4 and have IPv6 set for local traffic only. My ISP does not support IPv6 traffic ... at least, not yet.

I concur with MrHoffman, this issue appears to be on your local network.

Let's check Ethernet first ... as such, temporarily disable your Mac's Wi-Fi connection so we will only be testing the Ethernet one between your Mac and your Asus router.

Checking the Mac side first, go to System Settings > Network > Ethernet. For each setting on this pane:

• IPv4 Configured: I'm assuming that it is set for: Using DHCP ... correct?
• IP address: This would be the local IP address assigned by the DHCP service from the Asus. Does it look correct to you?
• Subnet mask: Should be 255.255.255.0
• Router: Should be the LAN-side IP address of your Asus.
• DNS Servers: There should be a pair of DNS servers listed. Depending on how you have your network configured, these could be the ones that your ISP is providing you, or ones you specifically set up manually. Regardless, do they look correct to you?

For now, we can ignore the Seach Domains & IPv6 address settings.

Now select the Details... button. The first window would be for the "Limit IP address tracking" setting. This setting may be grayed out. Regardless, we can ignore this one as well for now.

Select the TCP/IP tab. Since we are only concerned about IPv4 for now, you can optionally reconfigure the Configure IPv6 setting to Link-Local Only which would effectively disable IPv6 traffic coming/going from/to the Internet via the Asus.

Select the DNS tab. Again, you should be familiar with the DNS IP addresses listed here. If they are grayed out, that means that they are being assigned to your Mac from the Asus.

Select the 802.1X tab. Unless your network requires the use of an user authentication server, then the "Enable automatic connection" setting should be disabled.

Select the Proxies tab. Unless your network requires the use of proxies, all of the settings should be disabled.

Select the Hardware tab. Unless you need to use specific settings, like the use of Jumbo frames, the Configure option should be set to: Automatically. Now check the Speed, Duplex, and MTU settings. Are they what you expect for your network configuration. For example, for a 1 Gbps connection between your Mac and the router, Speed should be set to: 1000baseT. The AVB/EAV mode setting can be left enabled.

Now with these settings checked, we are going to do some simple ping tests between your Mac and the Asus, starting at the Mac end.

• Ping Loopback Address to verify that TCP/IP is functioning on the Mac's Ethernet interface:
  • ping -c3 127.0.0.1
• Ping Localhost to test the host name cache resolution:
  • ping -c3 localhost
• Ping the Mac's IPv4 Address to test the Mac's IPv4 address:
  • Use ipconfig getifaddr en0 to display the Mac's IP address assigned to the Ethernet interface (en0)
  • ping -c3 <Mac's IP address>
• Ping the Mac's Host Name:
  • Use hostname to display the Mac's host name.
  • ping -c3 <hostname>
• Ping the default gateway (your Asus)
  • ping -c3 <LAN-side IP address of the Asus>

Note: All of these pings should result in three packets being sent & received without any error and with very little latency.

I have a very similar problem with an OSX VM. It's just one of many VM's, linux and windows and they all work wonderfully. But the Sonoma vm has unusable ipv4 upload speed locally, to another VM. It can download from that very same vm fine. I scp big tarballs too and from the Mac and the linux web server...or that was the goal. But scp from the Mac to rhel9 either stalls or goes kb/s.

I disabled ipv6 but that didn't help. I run ipv4 locally. It's a deal breaker the way it is.

I watched the speedtest with Wireshark and it was indeed using ipv4 and upload was fine. This is wildly irritating.

Doing an scp I see a lot of dup ack's and retransmissions, and doubt that's good.

The hypervisor that all the vm's are on is connected to a C4948 with enterprise code. It's been a long time since I used this switch and it was a home lab vSphere san and vm back plane, so it probably has ether channel on all or most of the ports. Does Sonoma networking have any etherchannel stuff enabled under the hood by default? That shouldn't matter because all this networking is virtualized in the hypervisor. So it's clearly a OSX thing. It can't scp to anything locally at a usable speed.

You can see the scp is stalled in the console window at the bottom.

Just to be sure I understand. This "slow" network is your local network? That is between your Mac mini and your local network router?

If so, is this connection via Ethernet or via Wi-Fi. What is the make & model of your network router/gateway device? Which exact model is your mini? Is it running macOS Sonoma, as per your tagline?

FInally, how are you testing data transfer rates over your network?

What does traceroute show for the delays in the hops to 1.1.1.1 (Cloudflare) or to 8.8.8.8 (Google)?

traceroute 1.1.1.1

If you want us to look at that data, omit the first two or three hops from what gets posted for privacy.

iPerf is a diagnostics tool used to measure data transfer rates between two points on your local network in a client/server type of relationship.

However, before going there, I too would like to see the traceroute results that MrHoffman has asked you to run. This will help narrow down where the bottleneck(s) may be.

For Cloudflare (1.1.1.1) the total number of router hops can exceed 50+ depending on where you are located. The first hop should be between your Mac and your local router. That should be < 2 ms. The next hop should be between your router and your ISP. It should be under 15 ms, but it will be dependent on the ISP connection your ISP is giving you. From there most hops should be in the 20-25 ms range.

FWIW, I use a tool, called PingPlotter for this as it provides a more visual interpretation of the results.

Tesserax wrote:

... From there most hops should be in the 20-25 ms range. …

Why check the latencies and the hops with traceroute?

Time Warner / Road Runner / Charter / Spectrum (not sure what that ISP was called at that time) had one local network setup that was clearly traversing every coax cable TV link on the way through to the ‘net (and slowly), and they had a couple of IP routers in that whole networking morass that were randomly but all too often incurring ~500ms to ~1000ms latency delays; a half to a second for that hop.

Horrid latencies, in short.

Played havoc with network activity, too.

They really needed some better backhaul.

I think they finally fixed that.

MrHoffman wrote:

Why check the latencies and the hops with traceroute?

Simply as one tool to help determine where the bottleneck may exist before contacting my ISP when either the "Internet is down" or speeds are not what I expect then to be. With DSL service, yes it still exists, any "perturbation in the force" is highly undesirable. Can't wait for fiber, but where I'm located, it may not come in my lifetime. ;)

Tesserax wrote:

MrHoffman wrote:

Why check the latencies and the hops with traceroute?

Simply as one tool...

[that was rhetorical]

OP: yeah, ISP and network latencies are fine there. This isn't an IPv4 problem with the ISP, or with the internet link. This is seemingly an IPv4 or interference or bad cable or misconfiguration or some other issue within the local network, or a problem one of the associated network boxes on the network.

IIRC, ping, dig, and ilk will bypass the local network name caches.

scutil is the tool to use, there.

man scutil for details.

Semi-related: https://krypted.com/mac-security/programmatically-grab-active-dns-servers-macos/