Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It seems as though, from what I have read, that there may be another app/tool that is tinking with the time other than NTPD?
from yesterday checking HWclock against system time after doing a ntpdate sync and starting NTPD again it would slowly creep ahead, but never more than 5 seconds
Code:
Thu 01 Dec 2011 01:22:22 PM PST -0.665057 seconds
Thu Dec 1 13:22:23 PST 2011
and then it would appear to sync and bring in back inline.
Code:
Thu 01 Dec 2011 01:28:26 PM PST -0.529493 seconds
Thu Dec 1 13:28:26 PST 2011
Then this morning I checked HWclock against system time and it ~5 min off. Now in the afternoon its 8 minutes off:
Code:
Fri 02 Dec 2011 08:49:05 AM PST -0.417030 seconds
Fri Dec 2 08:52:24 PST 2011
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
You might want to check the battery if it's an older box (the hardware clock runs from the battery and if the battery is low, dead or whatever...). This will be a problem if the system is turned off between sessions.
Another thing you might want to look into is the hwclock utility, the section on --adjust and the section The Adjust Function about line 280-ish in the manual page. You can "walk" the adjustment (carefully! a little at a time) to bring the hardware clock in sync with the system clock.
Additionally, look at the drift file in /etc/ntp. There should be a floating-point number there; if /etc/ntp/drift does not exist, do something like this
Code:
echo 0.0 > /etc/ntp/drift
Might help.
Of course, if your NTP stuff isn't in /etc/ntp, adjust the above to where it actually lives.
From your other post it appears that you are polling the desired timer server. I never saw it synched i.e. the * before the server name in the output of the ntpq -p command. If you zero out the drift file it will take 900s or so for ntp to perform its inital calibration.
The hardware clock is not very accurate and I believe that if the system clock is synched via ntp it will be updated every 11 minutes.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by Cyked
Doesn't the hwckock cmd tell me the hardware time? That is actually acurate.
Yes, it does -- which indicates that the system clock isn't getting synchronized by NTP.
When you're in sync, running ntpq -p will show something like this:
Code:
/usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 12h 64 0 0.000 0.000 0.000
+247.conarusp.ne 216.218.254.202 2 u 870 1024 377 1324.69 -4.405 68.871
*ntp.cox.net .GPS. 1 u 756 1024 377 1493.03 15.182 16.085
+rapture.knovide 64.90.182.55 2 u 317 1024 377 1703.45 -73.680 53.170
The asterisk indicates that the clock is synchronized to ntp.cox.net.
So, take a look at your /etc/ntp.conf and perhaps try this:
Code:
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
#server pool.ntp.org
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
The local clock set to stratum 10 is a fall-back for when the network goes away (NTP will initially synchronize LOCAL, then to an external server, and more or less syncs to itself for a while when the network goes away).
The three pool servers allow NTP to synchronize to the best electrically close external server; I use three US pool servers -- if you're not in the US, you can choose from pool servers in your area or simply
Code:
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
Bottom line: if you run ntpq -p and do not see the display similar to the above, your system clock is not synchronized and it will wander all over the place.
The only purpose of the hardware clock is to provide a time source for the system clock when the computer is powered on. The hardware clock and system clock are independent of each other. The hardware drift correction is stored in /etc/adjtime and the system clock correction is stored in the ntp driftfile.
To be clear. I don't expect my system to sync to the hw clock. If I reboot system syncs to the hw clock correctly. I hardly reboot so drift happens when on. I reboot maybe once q month. If that.
[Quite]
Have you made any recent changes to your system?[/QUOTE]
This has been going on for months
Ill try some of things suggested above next time I remote in. Thanks for the tips so far. Ill repoet back.
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
time-a.nist.gov .ACTS. 1 u - 64 1 123.235 -171828 18.926
mail.freerip.co 67.18.187.111 3 u 3 64 1 34.384 -171826 0.001
ponderosa.piney 64.90.182.55 2 u 2 64 1 102.507 -171827 0.001
ntp1.Rescomp.Be 169.229.128.214 3 u 2 64 1 15.667 -171827 0.001
clock.trit.net 192.12.19.20 2 u 1 64 1 36.483 -171827 0.001
I added the "fudge 127.127.1.0 stratum 10" to my ntp.conf file.
What SHOULD the drift file have? x.xxx, but previously my drift file was something like -10.197. Should it be a negative number?
After making the changes (i reverted the drive file to -10.197 it was a few days ago, and adding back the ntp pool servers to the conf file), stopping and starting NTP...
My system time is synced and OK. BOTH these times are very very very close to my Win7 machine. I'll see what happens the remainder of the day and check, and check times again in the AM.
Code:
sudo hwclock;date
Mon 05 Dec 2011 09:22:12 AM PST -0.076789 seconds
Mon Dec 5 09:22:12 PST 2011
Wait until the value of reach becomes 377 and post the output of ntpq -p again. Hopefully your system will show that it is synced to a time server.
Yes, it can be a negative number. Depends if your system clock runs fast or slow.
The output does not show your computer locked to a time server i.e. (*).
You restarted ntp but output does not show your local (fudge) clock.
Your offset has decreased from ~171 seconds to ~7 so something is happening...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.