My system’s been having trouble downloading documents lately, and I can’t figure it out. For the last 30+ years, it’s all gone fast. But over the last few months, downloading files show up in the Downloads window and then sit there with the dot-downloads suffix forever. And now and then it all goes fast, as before.
Nothing’s different that I can see. Activity Monitor shows no abnormally high CPU or memory use. The disk has plenty of empty space.
Very puzzling. Does anyone have suggestions? Has anyone else seen this behavior?
I would try a ping test, which sends a stream of network packets to a particular machine on any reachable network and waits for replies from the target machine. When a network connection is unstable, it will “drop” some of these packets, which can cause downloads to take excessive time or to fail.
For example, if you open a Terminal.app window and type ping 8.8.8.8, you’ll see something like this:
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=119 time=20.362 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=20.342 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=12.391 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=6.670 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=16.244 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=119 time=19.933 ms ^C
-– 8.8.8.8 ping statistics —
6 packets transmitted, 6 packets received, 0.0% packet loss
(8.8.8.8 is the address of one of Google’s public DNS servers.) On a solid network connection, you’ll see 0% packet loss, or maybe loss of only one packet here or there, and the report times should be around 30 ms or less. Type control-c or ^c to exit from ping. If you lose packets, you’ll see either a “timeout” message or “lost packet” error.
If you’re not comfortable on the Terminal command line, there are some graphical network diagnostic tools that will perform ping tests and other tests. For example, the free Neo Network Utility is from a reputable devloper and is available at:
A ping test won’t solve your problem, but it can help identify the issue.
I could have given you slightly better advice! Try a ping test on the site you are downloading from. For example, if you are downloading a file from downloads.mycompany.com, try entering “ping downloads.mycompany.com” (without the quotes).
You could also try a “Trace” to the sites you are trying to download from and see how convoluted the data route is (multiple traces will allow you to see how consistent the route from your computer to the server is).
Okay, that rules out a general networking issue that you might be able to fix. Since you’re able to start the downloads, and assuming that you are running relatively current versions of macOS and your web browser, the issue most likely is on the server. You might try contacting the site and telling that downloads aren’t completing, even though you are getting excellent ping times to the server.
It may sound silly, but if you haven’t rebooted in a while, I’d also try that. I don’t know why, but Safari occasionally “gets stuck” trying to download or view things. When that happens, rebooting or clearing caches often helps.
Another idea: When a website stops working properly, clearing your history, cache, and cookies can often fix the issue. You can do that through Safari>Settings>Privacy>Manage Website Data. Search for the website, select it, and click the ‘Remove’ button. Then restart Safari, enter your credentials, and try to download again.
I used this trick this morning to get updated information from a website that showed no new information for a week after I requested it. I tried another computer (actually the Safari browser on my iPad), and the documents loaded. I went back to my desktop Mac, but I had no success until I followed the steps above.
HTTP connections (and those used for most other file-transfer protocols) run over the TCP protocol, which involves creating and maintaining connection state in the OS kernel.
Pings, on the other hand, use the ICMP protocol (specifically, its echo-request and echo-reply messages), which is stateless and shouldn’t involve any kernel state beyond what’s needed to transmit or receive a single packet.
In other words, the two protocols go through different paths in the kernel. So if one succeeds and the other fails, it doesn’t automatically rule out a local problem.
I’m thinking of the recently-reported macOS 49 day bug, which breaks the TCP protocol on Macs that have been running for a long time without rebooting.