NTP on Tiger

I am having the same problem here. I noticed that the ntp server is seen as stratum 16 from the client. From what I have read, ntp doesn't synchronize with stratum 16.

I'm wondering whether this may be due to DNS not loading properly on startup, therefore hanging ntpd. The dead ntpd is preventing further ntpd and ntpdate processes from starting.

Try doing a "top" in terminal, and scanning through the list to seach for "(ntpd)". You could also do a "ps -aux | grep ntpd" to see processes with "ntpd" in the name.

You could "sudo killall ntpd" (or "sudo kill -TERM ###" where ### is the process ID, or pid) -- or log into the server remotely as root ("ssh -l root xxxxxxx", where xxxxxx is the IP address or domain name of the server) to avoid having to "sudo" everything.

The Network Time startup item in /System/Library/StartupItems checks for network, and then goes ahead and syncs time and then launches the time server:

StartService ()
{
if [ "${TIMESYNC:=-YES-}" = "-YES-" ] &&
! GetPID ntpd > /dev/null; then

CheckForNetwork

if [ -f /var/run/NetworkTime.StartupItem -o "${NETWORKUP}" = "-NO-" ]; then exit; fi
touch /var/run/NetworkTime.StartupItem

echo "Starting network time synchronization"

# Synchronize our clock to the network's time,
# then fire off ntpd to keep the clock in sync.
ntpdate -bvs
ntpd -f /var/run/ntp.drift -p /var/run/ntpd.pid
fi
}

StopService ()
{
if pid=$(GetPID ntpd); then
echo "Stopping network time synchronization"
kill -TERM "${pid}"
else
echo "ntpd is not running."
fi
rm -f /var/run/NetworkTime.StartupItem
}

You might try checking /var/run for the ntpd.pid and ntp.drift files, which would indicate that time services were launched on startup, and the NetworkTime.StartupItem which indicates it was started by the script in /System/Library/StartupItems.

NTP on startup seems to be pretty much hit-and-miss for me...though if the PRAM battery is dead, that'll mess things up pretty badly and even manually trying to sync the clock to time.apple.com will fail (a definite indicator of a dead battery is that your time zone reverts to Cupertino...unless, that is, you actually live there, of course; I've had weird time problems when the time zone is correct for me too, so don't let this be the only indicator). I've been changing the batteries in all our servers, and NTP seems to be running a bit better ever since.

ntpq -c peers

from a client will show the status of your time server. If you try it from the server, it will show how well its time source is working (I usually sync to time.apple). I haven't had problems with stratus of 16.

One thing that flumoxed me when I first started using NTP on the servers was that I was coincidentally synching the servers' clocks with Retrospect every night, and seemed to throw off the time enough that NTP didn't work by the next day.

I have seen this problem with WinXP Trying to sync with OS X Server. It says that the Stratum I'm trying to sync from is lower than the client. Not sure how to fix that.