ntpd and Re: [ltp] getting correct time on a laptop (IBM ThinkPad T23)

[Florian Reitmeir]

On Mon, 26 Jun 2006, Martin Steigerwald wrote:
> Am Montag 26 Juni 2006 00:13 schrieb Florian Reitmeir:
> > On Son, 25 Jun 2006, Martin Steigerwald wrote:
> > > Am Sonntag 25 Juni 2006 20:06 schrieb George Yanos:
> > > > I've been reading along on this thread and have a question.  What
> > > > is the reason NOT to use ntpd by itself.  It seems to keep my
> > > > laptop perfectly in sync with my time server, which keeps itself
> > > > perfectly in sync with USNO.
> > > my laptop is without network connections for several days sometimes
> > > and the hardware clock is very inaccurate. I did not record it
> > > exactly, but 5 minutes off in 1-2 days is easily possible.
> > > Chrony records that inaccuracy even without network access - as good
> > > as it can estimate it - and adjusts its the clock accordingly.
> > i hope it common knowdledge that the linux kernel doesn't use the
> > hardware clock to measure time.

> on start it copies the hardware clock time to the system clock... when the 
> hardware clock has been inaccurate, it uses an inaccurate time to begin 
> with. Chrony accomodates for this situation when it is working properly.
> 
> Also chrony makes sure the hardware clock is synchron with system clock 
> when rtcfile is defined. If it can access NTP servers and is switched 
> online, it synchronizes system clock time with NTP time.

maybe its a good idea if we refer the varios pieces of hardware a unique name, so there are
RTC, System Clock, NTP

RTC is used to read the time at booting. NTP is used to sync the
systemclock, a Time Daemon calculate the drift of the systemclock, and the
drift of the RTC(s).

> > the kernel uses one of the timer to measure time, and time should
> > always go forward and never jump backward. (ntpdate via cron is a
> > really good way to crash filesystems/databases ...)
> I know that software may misbehave on such time changes, but how could a 
> filesystem crash? The integrity of a filesystem IMHO should never depend 
> on a working clock. Do you have any details on this?
I had really bad crashes of databases of all kind when time is stepping
backward.. problem is normally the transaction log of a database. Its rare
but happend to me often enough to simply run an ntpd of my servers, and do a
ntpdate only at booting (btw ntpdate per cron really also is a bad thing for
the pool.ntp guys because it issues a heavy load in on second per hour from
many computers)

> > - ntpd is a finetuning tool, its not designed to make large adjustments
> 
> Chrony seems to do a larger adjustment, when it is started - to accomodate 
> for the inaccuracy of the hardware clock... but when its running it does 
> small adjustments as well.

normally the time daemons like openntp and chrony, only do that thing of
adjustment at startup, because there are some embedded systems (like WRT54)
which do not have a RTC so after booting time is always at 1970s.. 

If the clock is wrong by several minutes an hour, none of the normal time
daemons can correct this.

> > - adjtimex is the tool to get really broken hardware in shape..
> 
> adjtimex seems to need quite some manual interaction aka "adjtimex -h 
> pool.ntp.org" to get it at least approximately right. Chrony seems to do 
> a better job, when I work around its limitations (doesn't detect 
> automatically whether NTP servers are accessible).

adjtimex is normally only used after installation, then if you corrected the
time, you put it static in the startup scripts (it corrects the "ticks" value
of the kernel)

> > so in your case, first..
> > - test the bios time, is it working correct? (read it, turn the laptop
> > off, read it again.. )
> 
> Well its not working accurately. Probably I didn't tell it clearly yet, 
> but my observations have been that time is inaccurate after the laptop 
> has been switched off for a while. 
> I know I should replace the CMOS battery, but until I manage to do that I 
> still want to have correct time on that notebook.

how many minutes is the drift? (per hour/day)


-- 
Florian Reitmeir