Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

clock runs fast

T

truffleupagus

macrumors newbie
Original poster
Jan 21, 2008
5
0
I just got a new 3GHz Mac Pro and I've discovered that the clock runs fast. It's off by a few minutes every hour and I need to constantly go to the Date&Time control panel to automatically set the time. This seems to also affect QT playback - when watching a long video in full screen mode, it'll shrink back to normal size a minute before the video is done playing. This is about the same time-offset as the clock.

I don't even know where to begin debugging this problem. I posted on the Apple discussion boards but all I got were replies wishing me luck.

Does anyone have any advice?
 
Yes, it is. In fact, it's the only way I can keep track of the correct time. I have to go to Date&Time and force it to resync to the correct value.

How frequently should it be auto-updating, anyway? I know it didn't didn't check once overnight, since my clock was off by 45 minutes when I woke up this morning.
 
Just a guess, but I would suggest that there is a parameter somewhere that has been set based on a 2.8GHz machine. If that's the case then your clock will be fast by a factor of 2.8/3.0 which means your clock will pass an hour in 56.0 minutes of real time.

Can you disable the network clock sync and then measure the real time elapsed for one hour to show on your computer and see how it compares.

If you look in "About this Mac" does it report 2.8GHz or 3.0GHz?
 
truffleupagus said:
I just got a new 3GHz Mac Pro and I've discovered that the clock runs fast.<snip>

Does anyone have any advice?
Click to expand...

Bring up a terminal and type 'ntpdc -np' and post what you see. Mine looks like this:

Code: 
$ ntpdc -np
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*17.254.0.31     192.168.1.14     2   64  177 0.07202  0.001858 0.25690
 
I just changed the battery, and that's not it. Nice try, though.

The clock is about 4 seconds per minute (or minutes per hour) off, so the 2.8ghz thing might be the right direction. I don't know much about 'sysctl -A', but nothing in there indicates a 2.8ghz baseline.

ntpdc -np looked like this:
Code: 
     remote           local      st poll reach  delay   offset    disp
=======================================================================
=17.254.0.31     192.168.1.105    2   64    3 0.03751 -4.287834 1.98436

then, a few minutes later, it looks like this:

Code: 
     remote           local      st poll reach  delay   offset    disp
=======================================================================
=17.254.0.31     192.168.1.105    2   64   17 0.03751 -4.287834 0.96915

At least the offset is consistent.
 
truffleupagus said:
I just changed the battery, and that's not it. Nice try, though.

The clock is about 4 seconds per minute (or minutes per hour) off, so the 2.8ghz thing might be the right direction. I don't know much about 'sysctl -A', but nothing in there indicates a 2.8ghz baseline.

ntpdc -np looked like this:
Code: 
     remote           local      st poll reach  delay   offset    disp
=======================================================================
=17.254.0.31     192.168.1.105    2   64    3 0.03751 -4.287834 1.98436

then, a few minutes later, it looks like this:

Code: 
     remote           local      st poll reach  delay   offset    disp
=======================================================================
=17.254.0.31     192.168.1.105    2   64   17 0.03751 -4.287834 0.96915

At least the offset is consistent.
Click to expand...

I really doubt the drift has anything to do with 2.8 vs 3.0 cpu frequency.

In the output above, the = at the beginning of the line indicates that you are polling the server and after some time you should sync. The reach indicates that ntpd has been successful each time it has tried to ping the server, but it hasn't been running very long.

I wonder if you're throwing things off by manually setting the time and confusing ntpd. I would recommend the following (keep in mind I'm very familiar with Unix, fairly familiar with NTP, but pretty new to Mac OS):

- Find the ntpd drift file. From a terminal 'ps auxw | grep ntpd' should give you a hint of where to look. The file name should be something like ntp.drift.

- Shut down the ntpd daemon and delete the drift file.

- Reboot your machine. When your machine restarts it should sync with the apple ntp server.

- Let your machine run for a couple of days without going to sleep. This will allow ntpd to poll apple's time server over a long enough period of time to get an accurate idea of how rapidly your clock drifts from real time. Ntpd will at some point write a new ntp.drift file. During this time, if your machine doesn't sleep and ntpd is able to contact apple's time server ntpd should keep your clock fairly close to accurate (within 1/2 sec.)

If after that, your machine doesn't keep good time, your hw clock may be so bad that ntp can't keep it in sync.

If it does keep good time, once ntpd has a good drift file, it can keep your clock in sync, even if internet access is cut off for a while. I would guess that sleeping would not be harmful to good timekeeping either after this point.

Good luck

-K
 
I wasn't entirely sure how to stop ntpd (online docs don't seem to match OS X's set-up) but I was able to delete the drift file anyway. I restarted about an hour ago and the drift file regenerated. The clock continues to stray but I guess I'll give it a couple of days.

How often is ntpd supposed to check in with the server? Once every 24 hours? It's certainly not once an hour or else the clock wouldn't drift so far over night, right?
 
truffleupagus said:
I wasn't entirely sure how to stop ntpd (online docs don't seem to match OS X's set-up) but I was able to delete the drift file anyway. I restarted about an hour ago and the drift file regenerated. The clock continues to stray but I guess I'll give it a couple of days.

How often is ntpd supposed to check in with the server? Once every 24 hours? It's certainly not once an hour or else the clock wouldn't drift so far over night, right?
Click to expand...

The 'poll' column in the ntpdc output shows how frequently ntpd checks the server. Your's showed 64 seconds. Each time it checks, it may slightly slow down or speed up your clock to cause it to eventually converge on reality. This way it keeps your time close to accurate without the time jumping forward or backward. However, if your hardware clock is defective and gains or loses time too rapidly, ntp won't be able to keep it stable.

If it drifts dramatically over night, and you didn't have a bogus drift file and the machine wasn't going to sleep, you may have a bad clock.
 
All modern computers have a built-in independent real-time-clock. You set it with software, but it runs independently.

If your time is drifting, then take the computer back.
 
I figured it out.

It seems my new Mac Pro doesn't like it when you install either the Leopard retail Client or Server (I had Server running). If you install with the disks that come with the box, you're good. Anything else is, I guess, out of date. ntpd certainly wasn't working quite right so it must be some pretty low level stuff going on.

I wasn't the only one having this problem. Hopefully, Apple will fix this soon.
 
truffleupagus said:
I figured it out.

It seems my new Mac Pro doesn't like it when you install either the Leopard retail Client or Server (I had Server running). If you install with the disks that come with the box, you're good. Anything else is, I guess, out of date. ntpd certainly wasn't working quite right so it must be some pretty low level stuff going on.

I wasn't the only one having this problem. Hopefully, Apple will fix this soon.
Click to expand...

That would explain it. Didn't realize you were using older versions of the software.

Apple always ships their new computers with a slightly revised version of the Mac OS if the new system was released AFTER the last public update to OS X.

The reason, is that the older version of OS X is unaware of the specifics of the newer machine. The version of OS X that comes with the computer has been updated with the required drivers and other adjustments to enable it to work properly (as will future updates to the retail package).
 
Aha, so it was a matter of using an older 10.5 build. The early 2008 mac pro requires the 9B116 build of 10.5.1 to function correctly. OS X Server will continue to have the issue until the 10.5.2 update.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back