28

it happens couple times every day, my MacBook becomes extremely slow. When I check Activity Monitor, I see that ntpd process uses more than 100% of my CPU (usually around 140-180%).

If I kill it (Force Quit), MacBook starts working as usual. But it will happen again in several hours. How can I fix this issue? It becomes really annoying

It started after one of the software updates (not sure exactly when).

MacBook Pro (Retina, 13-inch, Late 2013) with macOS 10.12.3

Improve this question
3
  • 3
    Go to System Preferences > Date and Time (unlock if needed) and uncheck Set date and time automatically. Close System Preferences, then reopen and re-check Set date and time automatically. Make sure the time server info is correct for your location on the planet.
    – IconDaemon
    Mar 7, 2017 at 1:58
  • just did it, will check in a few hours if it helped, thanks
    – user159846
    Mar 7, 2017 at 2:42
  • @IconDaemon looks like it helped. If you can post your solution as an answer, I will confirm it
    – user159846
    Mar 20, 2017 at 5:09

2 Answers 2

Reset to default
37

Go to System Preferences > Date and Time and uncheck Set date and time automatically. Close System Preferences, then reopen and re-check Set date and time automatically

Improve this answer
4
  • Thanks for answer - this helped resolve my 200% utilized process. I presume this is an OS bug? Has it been reported to Apple?
    – J.D.
    Jul 31, 2017 at 15:31
  • 1
    What a broken Mac is, I constantly fight some internall stuff eating CPU. Today is ntpd.
    – Johnny_D
    May 7, 2018 at 19:09
  • 1
    I tried just unchecking because I didn't mind if it did not auto-update, and that was not sufficient. I had to uncheck and recheck to fix the problem, and then I could set the check however I liked. Also ntpq -p in the answer below was useful as a diagnostic because it timed out until the problem was fixed and CPU back near zero.
    – Joshua Goldberg
    Oct 26, 2018 at 15:32
  • On one occasion, this did not work, and I was told by our help desk about an alternate fix: On the Date and Time tab, I had to change the server to Apple and then back to our work server. (There are authentication-related reasons to keep it pointed at the work-managed server.)
    – Joshua Goldberg
    Mar 18, 2019 at 19:02
5

Check if the NTP servers you have configured are correct and reachable.

Open a Terminal window and run

ntpq -p

This is the output I got on my system which had ntpd using around 80-90% cpu.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*aer-foo5d20-dc- .GPS.            1 u   23   64   17   17.888   20.617   2.226
 aer-foo6t20-dc- .GPS.            1 u   23   64   17   17.938   20.598   2.211
 defra1-ntp-001. .INIT.          16 u    -  68m    0    0.000    0.000   0.000

This shows that I had 3 ntp server configured, the 2 first ones are ok but the 3rd one was unreachable (I'm no NTP expert but refid=.INIT., st=16 and reach=0 all seem to indicate something is wrong).

So I went to System Preferences > Date and Time , where indeed I had 3 ntp servers configured: 2 inside my company's network, and time.apple.com - so nothing resembling "defra1-ntp-001". Assuming "defra1-ntp-001" referred to time.apple.com I removed that one, and this resolved my problem.

Of course in my specific case, probably time.apple.com was unreachable because it is blocked by my company's firewall, so I don't recommend removing it as a general solution. Instead check your 'ntpq -p' output and try to determine which server is causing the problem and remove that one (and if none are left, add a known good one).

Improve this answer
1
  • 1
    I tried your suggestion and the query timed out. Then I followed the suggestion from the accepted answer and in System Preferences > Date and Time saw that my system is pointing to my corp ntp server. Then I ran the query again and this time it worked. Maybe some bug related to switching to VPN?
    – ajh158
    Mar 11, 2018 at 18:08

You must log in to answer this question.