login
Search
Does anybody knows how to force ntpd - the fully automatic daemon - to start synchronizing time? I presumed that it was designed to do. But it appears it doesn't.
I got several systems with really bad clocks drifting about minute per hour and try to sync them in automatic mode with ntpd. Sometimes ntpd works. But very often it sits in memory and does absolutely nothing. And logs have no error no warning - just heap of messages from start-up.
The only reliable solution I have found is to kill the ntpd and run ntpdate from cron every half hour. That works, though not nice: everybody tells me during last decade that ntpdate is deprecated and shouldn't be used.
From all I have read about ntpd - except its unparsable/unreadable man page - says that my problem should be solvable by ntpd automatically, but even adding undocumented parameters ('iburst' or something like that) to ntpd.conf did not help.
It's not the first time I have such trouble: but on other systems it is less critical, since there clocks are Ok.
Does anybody has any clues? Is it only me who have that problem?
ntpd trick...
you've to wait... ntp just accelerates/slowdowns the clock speed, but it doesn't set the clock directly! It's because that the "time is a continuum", especally filesystems are pretty picky about time.
(btw, if you want a daemon, which sets the time (if the drift is too bad) get chronyd!)
If your clock loses a minute
If your clock loses a minute an hour, that's amazingly bad. That's equivalent to saying that each minute has only 59 seconds for you.
I'm guessing that NTP cannot handle errors this serious-- it's mainly designed to give the clock a little nudge now and then, not to hit it with a hammer every minute.
I also suspect that your kernel is losing clock ticks for some reason.
It can't be a hardware problem-- nobody could build hardware that bad without going out of their way. Try setting CONFIG_HZ to some more generous value, like 100, and see if your clock keeps better time.
My clock drifts by ~30 second
My clock drifts by ~30 seconds per hour (this is on a very old computer)... but chrony has no trouble handling it.
I think ntpd's focus is on ke
I think ntpd's focus is on keeping very precise time, even down to the microsecond. To do this, it uses some fairly complicated and delicate algorithms.
chronyd seems to be more focused on getting things "close" for systems which may or may not have good network access or good hardware. There's even a mode where you can type in the time periodically if you have no network connectivity (sad indeed is the admin who has to resort to this.)
So maybe the OP should try chronyd, and see if it solves his problem.
NTP drift
It appears ntp should handle drift upto 5%, which is 3 seconds in every minute. So should easily cope with this amount of drift. However, ntp can take quite an amount of time to work out the amount of correction required. Synchronisation can take 15-20 minutes or more.
Andy
TimeTools NTP Servers
OpenNTPD
I would strongly suggest trying out OpenNTPD, especially with the "-s" option.
The man page nice and readable.
The previous poster is right though, that magnitude of clock drift is rather curious.
OpenNTPd works.
I have just tried OpenNTPd - with "-s" - and it helped.
I cannot figure my problem precisely: as soon as I start GUI on the system clock starts drifting. Under heavy load (cat /var/log/messages on xterm) clock does advances almost at double speed... :-/ Also problem worsens if system is up for a long time - then I do not need a xserver to observe drifting.
Hardware RTC bug, ACPI issue,
Hardware RTC bug, ACPI issue, etc. No NTP daemon will help you if the clock drift isn't predictable (eg. constant).
Linux doesn't use the RTC for
Linux doesn't use the RTC for the system timer.
Try using a different time source. Linux lately supports pmtimer, TSC, APIC timer, etc, but if all else fails, fall back to the 8259 timer.
Re: Unmanageable NTP daemon
You didn't provide much information to get any clues...
What does ntpq -p tell you (after a while)?
Perhaps dhcpcd is overwriting your ntp.conf, try starting dhcpcd with the -N option.
For ntp to work...
For ntpd to work properly (or at all), you need to sync the clock initially before starting the daemon. RHEL has an /etc/ntp/step-tickers file to set the time servers to set from. You can do this manually using ntpdate. If your clocks are really bad, then ntp won't be able to correct however. Try changing the clock device as others have mentioned.
chronyd problems
I've been using chronyd for some time and basically it work just fine. The problem is when I use it on a box with non-permanent inet connection, chronyd starts dropping ntp peers and after dropping them all, it starts to lose time.
echo "sources" | chronyc
shows no hosts in this case (as opposed to showing all hosts specified in config right after I start the daemon).
Any ideas what may be wrong or how can I tell chronyd not to drop sources?
http://chrony.sunsite.dk/guid
http://chrony.sunsite.dk/guide/chrony.html#Configuration%20for%20infrequ...
:)
Thanks but...
Thanks for the hint but I hadn't made myself clear enough last time. :-( My problem is that my connection is (supposed to be) permanent but it drops occasionally. I can't really tell the "gone online/offline" events so I can't tell chrony. :-(
Using cron+ping+whatever is a bit overkill, I just wanted to make chrony not drop sources when the polling fails...
Hmm, I guess you could add th
Hmm, I guess you could add the "auto_offline" option to all servers, then run a cronjob that sends the "online" command to chronyd every 10 (or so) minutes.
http://chrony.sunsite.dk/guide/chrony.html look under "4.2.32 server".