linux-kernel - Re: NTP time sync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Nov 2006 02:48:48 +0100
From:	Gabriel Paubert <paubert@...m.es>
To:	Alessandro Zummo <alessandro.zummo@...ertech.it>
Cc:	David Brownell <david-b@...bell.net>, akpm@...l.org,
	hackers@...ts.ntp.isc.org, Andi Kleen <ak@....de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ralf@...ux-mips.org, linuxppc-dev@...abs.org, lethal@...ux-sh.org,
	paulus@...ba.org, rmk@....linux.org.uk, Kim@...abs.org,
	davem@...emloft.net, kkojima@...iij4u.or.jp, mills@...l.edu
Subject: Re: NTP time sync

On Wed, Nov 22, 2006 at 09:23:55PM +0100, Alessandro Zummo wrote:
> On Wed, 22 Nov 2006 11:55:23 -0800
> David Brownell <david-b@...bell.net> wrote:
> 
> > > 
> > >  So, if the arch maintainers agree, 
> > >  I would suggest to schedule it for removal.
> > > 
> > > [1] http://lkml.org/lkml/2006/3/28/358
> > 
> > Suggested time of removal: one year after two relevant software
> > package releases get updated:
> > 
> >   - NTPD, to call hwclock specifying the relevant RTC;
> 
>  This might introduce delays. ntpd might open the device
>  and update the time itself.
> 

Indeed, the update should be at least _triggered_ by ntp.

In the end it will be the kernel that accesses the hardware,
the fundamental problem is that with RTC chips with very slow 
access like I2C it cannot be done from an interrupt.

But it nevertheless has to be done as close as possible
to the half-second or second boundary (depending on the chip) 
boundary if we want to keep some precision. You can't expect 
miracles from RTC chips in this respect, since the crystal
period is about 30µs to boot and from some tests I did a long
time ago it seems that most do not reset the first bits of
the divider when written to, so the precision is much worse
(something like 30ms IIRC). It is still much better than 1
second in any case.

How can ntp know if the RTC chip has to be updated at the 
half-second or second boundary? That is the kind of knowledge
that is better left to the driver.

	Regards,
	Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/