Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Diagnosing a drifting time clock problem Network

If you've had a problem keeping your clock accurate using network time, this tip may help out. Network time is controlled from the System Preferences, Date & Time pane, Network Time tab. Symptoms of the problem include:

  • The "Use a network time server" checkbox turning itself off after a restart.
  • The clock drifting even though the "Set Time Now" button seems to work.

OS X has a confusing "feature" that makes diagnosing the problem difficult: After a restart or after disabling and enabling the "Use a network time server" checkbox, OS X attempts to synchronize the time using a different method than when you press the "Set Time Now" button. After a restart or enabling "Use a network time server," OS X sends Network Time Protocol (NTP) messages using the User Datagram Protocol (UDP) from port 123 of your machine to port 123 of the specified NTP Server. The server replies from port 123 to port 123 of your machine.

After pressing the "Set Time Now" button, OS X sends NTP messages from a very high port number (about 49150) of your machine to port 123 of the NTP Server. The server replies from port 123 to the same high port number of your machine.

Read the rest of the article for information on diagnosing and repairing this problem...

Diagnosing NTP
To see if you have a problem, enable the "Use a network time server" checkbox and press the "Set Time Now" button. Open the terminal and type ntpq -p. If ntpq outputs ntpq: read: Connection refused, then the "Use a network time server" checkbox is probably not enabled. If ntpq outputs No association ID's returned, then no NTP messages at all are getting through. If the ntpq output has a 16 in the st (stratum) column, then the (123/123) NTP messages are not getting through but the high port numbered "Set Time Now" messages are being received:

remote      refid    st t when poll reach   delay   offset  jitter
=====================================================================
[server]  0.0.0.0    16 u    -  68m    0    0.000    0.000 4000.00

Where [server] is the specified NTP server.

If the ntpq output has a number lower than 16 in the "st" column, then NTP is working correctly:

remote      refid    st t when poll reach   delay   offset  jitter
=====================================================================
[server] [something]  2 u   48  68m    1  141.594   14.361   0.004
Fixing NTP
NTP problems are often caused by a firewall between you and the NTP server, either a software firewall on your machine or a hardware firewall at your Internet connection. Check to see if you have a software firewall installed, such as Brickhouse or have the Jaguar built-in firewall enabled in the System Preferences, Sharing pane, Firewall tab.

If you have no control over the firewall, the problem will be unsolvable, at least until Apple makes changes to OS X. Otherwise, you will want to reduce the firewall security by the smallest amount necessary to solve the problem. Note that traffic from the NTP server always:

  • uses the UDP (not TCP) protocol,
  • is from port 123,
  • is either to port 123 or to a port over 10,000,
  • is from the IP address of the specified NTP server.
At minimum, the firewall should be modified to only allow additional messages with the first three characteristics above. In Brickhouse and most other software firewalls, the appropriate filter lines are usually:
add [number1] allow udp from any 123 to any 123 via en0
add [number2] allow udp from any 123 to any 10000-65535 via en0
Where [number1] and [number2] are integers that specify the order in which to execute the filter rules. You can list the existing firewall rules within Brickhouse or with the terminal command sudo ipfw list. Other firewalls may have a different syntax; reading your firewall manual is required.
    •    
  • Currently 2.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[23,635 views]  

Diagnosing a drifting time clock problem | 4 comments | Create New Account
Click here to return to the 'Diagnosing a drifting time clock problem' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Diagnosing a drifting time clock problem
Authored by: awk on Feb 21, '03 02:47:19PM

In general, NTP client-to-server messages can have UDP source port 1024 or greater. Server-to-server are always 123 to 123 .. since the NTP daemon is both a server and a client, you see both.

Also, if you have a LAN, the firewall/gateway machine can synchronize to an external NTP server, and the internal machines can synchronize to the gateway.

One minor thing about setting the time that bugs me sometimes: you can't switch the time server setting automatically when you switch locations.



[ Reply to This | # ]
Dialup & network time
Authored by: huzzam on Feb 23, '03 05:18:53PM

I believe that if you have a non-persistent internet connection (eg dialup) your "use network time server" checkbox will always turn off during restart, because the server is always unreachable when you're starting up. Has anyone come up with a fix for this?

peter



[ Reply to This | # ]
ntpq -p host
Authored by: hayne on May 18, '03 04:15:09PM

The 'ntpq -p' command (recommended by the hint) needs to be supplied with the name of the time-server to be used. If you don't supply a hostname (i.e. you just do: 'ntpq -p') then it will use 127.0.0.1 as the time-server. This isn't likely to work.
The standard Apple time server is time.apple.com
So the command to issue to check for ntp problems is:
ntpq -p time.apple.com



[ Reply to This | # ]
ntpq -p host (NOT!)
Authored by: captain on Dec 23, '06 12:37:32AM

Actually "ntpq -p" should display all configured timeservers that localhost (i.e. the computer on which your shell is running) knows about and the data as mentioned above. If you type the host nothing should happen differently because:

from the man page:
-p Print a list of the peers known to the server as well as a sum-
mary of their state. This is equivalent to the peers interactive
command.

In other words: "ntpq -p" is equivalent to "ntpq -c peers", however "ntpq -p [hostname]" *should* just ignore hostname, while "ntpq -c peers [hostname]" should display all the know peers of hostname, NOT localhost.

Make sense? Good. :-)

RTFM next time, okay? :-P



[ Reply to This | # ]