diff for duplicates of <20061123014848.GA8675@iram.es> diff --git a/a/1.txt b/N1/1.txt index 7689f5e..febdaee 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,39 +1,39 @@ 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@pacbell.net> wrote: ->=20 -> > >=20 -> > > So, if the arch maintainers agree,=20 +> +> > > +> > > So, if the arch maintainers agree, > > > I would suggest to schedule it for removal. -> > >=20 +> > > > > > [1] http://lkml.org/lkml/2006/3/28/358 -> >=20 +> > > > Suggested time of removal: one year after two relevant software > > package releases get updated: -> >=20 +> > > > - NTPD, to call hwclock specifying the relevant RTC; ->=20 +> > This might introduce delays. ntpd might open the device > and update the time itself. ->=20 +> 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=20 +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)=20 -boundary if we want to keep some precision. You can't expect=20 +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=B5s to boot and from some tests I did a long +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=20 +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. diff --git a/a/content_digest b/N1/content_digest index e8e3e73..52c4ea6 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,62 +5,62 @@ "Subject\0Re: NTP time sync\0" "Date\0Thu, 23 Nov 2006 02:48:48 +0100\0" "To\0Alessandro Zummo <alessandro.zummo@towertech.it>\0" - "Cc\0akpm@osdl.org" - Kim@ozlabs.org - linuxppc-dev@ozlabs.org + "Cc\0David Brownell <david-b@pacbell.net>" + akpm@osdl.org + hackers@lists.ntp.isc.org + Andi Kleen <ak@muc.de> Linux Kernel Mailing List <linux-kernel@vger.kernel.org> ralf@linux-mips.org - David Brownell <david-b@pacbell.net> - Andi Kleen <ak@muc.de> + linuxppc-dev@ozlabs.org lethal@linux-sh.org paulus@samba.org - kkojima@rr.iij4u.or.jp - hackers@lists.ntp.isc.org - davem@davemloft.net rmk@arm.linux.org.uk + Kim@ozlabs.org + davem@davemloft.net + kkojima@rr.iij4u.or.jp " mills@udel.edu\0" "\00:1\0" "b\0" "On Wed, Nov 22, 2006 at 09:23:55PM +0100, Alessandro Zummo wrote:\n" "> On Wed, 22 Nov 2006 11:55:23 -0800\n" "> David Brownell <david-b@pacbell.net> wrote:\n" - ">=20\n" - "> > >=20\n" - "> > > So, if the arch maintainers agree,=20\n" + "> \n" + "> > > \n" + "> > > So, if the arch maintainers agree, \n" "> > > I would suggest to schedule it for removal.\n" - "> > >=20\n" + "> > > \n" "> > > [1] http://lkml.org/lkml/2006/3/28/358\n" - "> >=20\n" + "> > \n" "> > Suggested time of removal: one year after two relevant software\n" "> > package releases get updated:\n" - "> >=20\n" + "> > \n" "> > - NTPD, to call hwclock specifying the relevant RTC;\n" - ">=20\n" + "> \n" "> This might introduce delays. ntpd might open the device\n" "> and update the time itself.\n" - ">=20\n" + "> \n" "\n" "Indeed, the update should be at least _triggered_ by ntp.\n" "\n" "In the end it will be the kernel that accesses the hardware,\n" - "the fundamental problem is that with RTC chips with very slow=20\n" + "the fundamental problem is that with RTC chips with very slow \n" "access like I2C it cannot be done from an interrupt.\n" "\n" "But it nevertheless has to be done as close as possible\n" - "to the half-second or second boundary (depending on the chip)=20\n" - "boundary if we want to keep some precision. You can't expect=20\n" + "to the half-second or second boundary (depending on the chip) \n" + "boundary if we want to keep some precision. You can't expect \n" "miracles from RTC chips in this respect, since the crystal\n" - "period is about 30=B5s to boot and from some tests I did a long\n" + "period is about 30\302\265s to boot and from some tests I did a long\n" "time ago it seems that most do not reset the first bits of\n" "the divider when written to, so the precision is much worse\n" "(something like 30ms IIRC). It is still much better than 1\n" "second in any case.\n" "\n" - "How can ntp know if the RTC chip has to be updated at the=20\n" + "How can ntp know if the RTC chip has to be updated at the \n" "half-second or second boundary? That is the kind of knowledge\n" "that is better left to the driver.\n" "\n" "\tRegards,\n" "\tGabriel" -ada0c1eba5eef5fe3317641825480fb9032909384dbdcc4d9237a45808f69cc5 +4f43a7a7836f58bd92be668d5a2f39effb052fec30419388ec62de34de160ce9
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.