Re: [opensuse] chrony and hwclock



On Fri, Jul 15, 2011 at 10:19 AM, Anton Aylward
<opensuse@xxxxxxxxxxxxxxxx> wrote:
Roger Oberholtzer said the following on 07/15/2011 09:55 AM:
Systems that are on all the time or for very long periods of time do not
see the deficiency in ntp. It has become apparent in systems that are
off and on with some frequency. It is a recurring topic on the gpsd
mailing list.


You seem to have ommitted a number of things.

Many of us live on laptops that are "off and on with some frequency" and
don't always have internet connections or in circumstances where the
proxy doesn't allow NTP.

What NTP does do that you have ommited in this thread is also
significant.  It keeps track of drift of the system clock.
In fact when a reference is available it keeps track of the drift
continuously, so that when it starts up and isn't in contact with a
reference it can make a damn good estimate of what the time really is.

I believe that is the theory, but I setup a dedicated laptop to act as
a weather station a couple years ago. openSUSE based.

And I can say openSUSE on bootup does NOT behave that way. I suspect
ntpd is way too slow to kick off and get things straightened out.

I have not updated the distro since it is a dedicated purpose machine
and the is nothing of value on it, so I'd guess it is 10.3 or 11
based.

I can say with certainty that openSUSE on that laptop gets the time
horribly wrong on reboot. (ie. its off by months.)

NTP comes along and fixes it in short order, but I always have a few
weather readings from the wrong month in the mix. Fortunately the
bios date is months behind, so the data just impacts old data I don't
care about.

Roger, I suspect you need to decide if debugging the openSUSE bootup /
time control is what you should be doing vs.moving to Chrony.

I personally suspect Chrony won't help. Instead, I suspect the
problem is in the order of how the init scrips are called. That is
the bios clock is clearly used in the early boot phases and if you
start depending on the time prior to NTP / Chrony coming to life, you
get bogus data.

In my case, NTP uses the Internet sites for time but it seems to be
invoked before the network is up, so it takes quite a while to fix the
machines time. And when it does that, it must not be updating the
bios clock, or it wouldn't be so horribly far off.

Again, debugging the NTP setup / package is where I would focus
effort, not in switching to Chrony. Either way, you will likely have
to do your own package level debugging to get things the way you want
them.

Greg
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx



Relevant Pages

  • Re: AIX ntp.conf problem
    ... turned on on the DNS server and I can see the lookup requests. ... However...for ntp I don't see anything. ... I suspect there is a problem in ...
    (comp.protocols.time.ntp)
  • Re: Can we write NTP server using c#
    ... I m having code for ntp Client... ... But i want to wtite code for sever also.. ... Sure, but I suspect that since you ask the question, it is not possible for ...
    (comp.protocols.time.ntp)
  • Re: chrony and ntp comparison-- ADSL hookup
    ... different algorithm for clock discipline. ... Chrony had definite failures. ... If you crank the NTP time constant comparable to yours, ...
    (comp.protocols.time.ntp)
  • Re: oscillations in ntp clock synchronization
    ... The ntp oscillations are in the low usec range, but the room itself has no ... The chrony oscillations are 10's of milliseconds. ... The rate of clock queries in chrony has a max of 7 ...
    (comp.protocols.time.ntp)
  • Re: NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
    ... system is NOT following the real drift rate of the clock. ... The much better behaviour of chrony on offsets suggests that ntp is NOT ...
    (comp.protocols.time.ntp)