clock runs fast

Discussion in 'Mac Pro' started by truffleupagus, Jan 21, 2008.

  1. truffleupagus macrumors newbie

    Joined:
    Jan 21, 2008
    #1
    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?
     
  2. Jonny427 macrumors regular

    Joined:
    Oct 16, 2007
    Location:
    Orange County, CA
    #2
    Is your computer set to automatically sync with the time server? If so, i'd wait another day and see if its just a problem on their part.
     
  3. truffleupagus thread starter macrumors newbie

    Joined:
    Jan 21, 2008
    #3
    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.
     
  4. mrcandy macrumors regular

    Joined:
    Nov 12, 2007
    Location:
    Calgary, AB Canada
    #4
    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?
     
  5. iBook G4 FTW macrumors newbie

    iBook G4 FTW

    Joined:
    Jan 21, 2008
    Location:
    Vancouver BC, Canada
    #5
    "Replacing the Internal Backup Battery Your Mac Pro uses a CR 2032 Lithium battery that preserves settings, such as the date and time, when your Mac Pro is off. If you notice intermittent problems when your Mac Pro starts up or changes in the date and time settings, you may need to replace the battery."
    From http://manuals.info.apple.com/en/Mac_Pro_User_Guide.pdf Page 50
     
  6. lin2mac macrumors newbie

    Joined:
    Jan 21, 2008
    #6
    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
    
     
  7. truffleupagus thread starter macrumors newbie

    Joined:
    Jan 21, 2008
    #7
    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.
     
  8. kps macrumors regular

    Joined:
    Jan 10, 2008
    Location:
    kw.on.ca
    #8
    60 * (2.8 - 3.0) / 2.8 = -4.286

    mrcandy wins.
     
  9. lin2mac macrumors newbie

    Joined:
    Jan 21, 2008
    #9
    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
     
  10. truffleupagus thread starter macrumors newbie

    Joined:
    Jan 21, 2008
    #10
    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?
     
  11. lin2mac macrumors newbie

    Joined:
    Jan 21, 2008
    #11
    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.
     
  12. flyinmac macrumors 68030

    flyinmac

    Joined:
    Sep 2, 2006
    Location:
    United States
    #12
    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.
     
  13. truffleupagus thread starter macrumors newbie

    Joined:
    Jan 21, 2008
    #13
    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.
     
  14. flyinmac macrumors 68030

    flyinmac

    Joined:
    Sep 2, 2006
    Location:
    United States
    #14
    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).
     
  15. newtech macrumors 6502

    Joined:
    Jun 2, 2007
    #15
    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.
     

Share This Page