NTP time sync

NTP time sync

[Alessandro Zummo]

 wrto the in-kernel NTP synchronization,
 as discussed before [1], my opinion
 is that it should be done in userland.

 Keeping it in kernel implies subtle code
 in each of the supported architectures.

 So, if the arch maintainers agree, 
 I would suggest to schedule it for removal.

[1] http://lkml.org/lkml/2006/3/28/358


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

Re: NTP time sync

[Russell King]

On Wed, Nov 22, 2006 at 08:36:33PM +0100, Alessandro Zummo wrote:
> 
> 
>  wrto the in-kernel NTP synchronization,
>  as discussed before [1], my opinion
>  is that it should be done in userland.
> 
>  Keeping it in kernel implies subtle code
>  in each of the supported architectures.
> 
>  So, if the arch maintainers agree, 
>  I would suggest to schedule it for removal.
> 
> [1] http://lkml.org/lkml/2006/3/28/358

Fine, provided there's also a shell tool that can enquire whether the
kernel is sync'd or not.  (Currently the 11-minute update does not
occur when the kernel is desynced from a time source - the RTC itself
might be more accurate in this case.)

Throwing hwclock commands into crontab such that they do not take
note of the kernel's sync status is probably a very bad move in that
respect.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: NTP time sync

[Alessandro Zummo]

On Wed, 22 Nov 2006 19:51:53 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> >  So, if the arch maintainers agree, 
> >  I would suggest to schedule it for removal.
> > 
> > [1] http://lkml.org/lkml/2006/3/28/358
> 
> Fine, provided there's also a shell tool that can enquire whether the
> kernel is sync'd or not.  (Currently the 11-minute update does not
> occur when the kernel is desynced from a time source - the RTC itself
> might be more accurate in this case.)
> 
> Throwing hwclock commands into crontab such that they do not take
> note of the kernel's sync status is probably a very bad move in that
> respect.

 I agree. I would like to coordinate this effort together with
 the ntp folks so that we can find a viable solution.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

Re: NTP time sync

[David Brownell]

On Wednesday 22 November 2006 11:36 am, Alessandro Zummo wrote:
> 
>  wrto the in-kernel NTP synchronization,
>  as discussed before [1], my opinion
>  is that it should be done in userland.
> 
>  Keeping it in kernel implies subtle code
>  in each of the supported architectures.
> 
>  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;
  - util-linux, updating hwclock to know about /dev/rtcN;
  - busybox, with its own hwclock implementation.

The util-linux hwclock update is already in the queue, I'm told.

- Dave

Re: NTP time sync

[Alessandro Zummo]

On Wed, 22 Nov 2006 11:55:23 -0800
David Brownell <david-b@pacbell.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.

>   - util-linux, updating hwclock to know about /dev/rtcN;
>   - busybox, with its own hwclock implementation.
> 
> The util-linux hwclock update is already in the queue, I'm told.

 I suspect nobody would change NTPD if we don't
 schedule that feature for removal :)


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

Re: NTP time sync

[Gabriel Paubert]

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
> > >  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
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
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
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
half-second or second boundary? That is the kind of knowledge
that is better left to the driver.

	Regards,
	Gabriel

Re: NTP time sync

[Andi Kleen]

> [1] http://lkml.org/lkml/2006/3/28/358

What was the answer to Matt's last question in there?
If the existing user land does it already then 
probably.  If not then a good migration strategy would 
be needed.

-Andi

Re: NTP time sync

[Benjamin Herrenschmidt]

On Thu, 2006-11-23 at 11:54 +0100, Andi Kleen wrote:
> > [1] http://lkml.org/lkml/2006/3/28/358
> 
> What was the answer to Matt's last question in there?
> If the existing user land does it already then 
> probably.  If not then a good migration strategy would 
> be needed.

Couldn't we have a transition period by making the kernel not rely on
interrupts ? if the NTP irq code just triggers a work queue, then all of
a sudden, all of the RTC drivers can be used and the latency is small.
That might well be a good enough solution and is very simple.

Ben

Re: NTP time sync

[David Brownell]

On Thursday 23 November 2006 3:00 am, Benjamin Herrenschmidt wrote:
> 
> Couldn't we have a transition period by making the kernel not rely on
> interrupts ? if the NTP irq code just triggers a work queue, then all of
> a sudden, all of the RTC drivers can be used and the latency is small.
> That might well be a good enough solution and is very simple.

Good point.  Of course, one issue is that the NTP sync code all
seems to be platform-specific right now ... just like the code
to set the system time from an RTC at boot (except for the new
RTC framework stuff) and after resume.

- Dave

RE: NTP time sync

[Joakim Tjernlund]

> -----Original Message-----
> From: 
> linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozlabs.org 
> [mailto:linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozl
> abs.org] On Behalf Of David Brownell
> Sent: den 26 november 2006 00:22
> To: Benjamin Herrenschmidt
> Cc: akpm@osdl.org; Alessandro Zummo; linuxppc-dev@ozlabs.org; 
> lethal@linux-sh.org; Linux Kernel Mailing List; 
> ralf@linux-mips.org; Andi Kleen; paulus@samba.org; 
> rmk@arm.linux.org.uk; davem@davemloft.net; kkojima@rr.iij4u.or.jp
> Subject: Re: NTP time sync
> 
> On Thursday 23 November 2006 3:00 am, Benjamin Herrenschmidt wrote:
> > 
> > Couldn't we have a transition period by making the kernel 
> not rely on
> > interrupts ? if the NTP irq code just triggers a work 
> queue, then all of
> > a sudden, all of the RTC drivers can be used and the 
> latency is small.
> > That might well be a good enough solution and is very simple.
> 
> Good point.  Of course, one issue is that the NTP sync code all
> seems to be platform-specific right now ... just like the code
> to set the system time from an RTC at boot (except for the new
> RTC framework stuff) and after resume.
> 
> - Dave

Looking at rtc-dev.c I don't see a MARJOR number assigned to /dev/rtcN. Seems like
it is dynamically allocated to whatever major number that is free.
Is that the way it is supposed to be? How do I create a static /dev/rtcN in my /dev
directory if the major number isn't fixed?
Maybe I am just missing something, feel free to correct me :)

 Jocke

Re: NTP time sync

[Alessandro Zummo]

On Sun, 26 Nov 2006 12:04:54 +0100
"Joakim Tjernlund" <joakim.tjernlund@transmode.se> wrote:

> Looking at rtc-dev.c I don't see a MARJOR number assigned to /dev/rtcN. Seems like
> it is dynamically allocated to whatever major number that is free.
> Is that the way it is supposed to be? How do I create a static /dev/rtcN in my /dev
> directory if the major number isn't fixed?
> Maybe I am just missing something, feel free to correct me :)

 udev ;)

 the concept of static numbers is quite old...

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

RE: NTP time sync

[Joakim Tjernlund]

> -----Original Message-----
> From: Alessandro Zummo [mailto:alessandro.zummo@towertech.it] 
> Sent: den 26 november 2006 20:22
> To: Joakim Tjernlund
> 
> On Sun, 26 Nov 2006 12:04:54 +0100
> "Joakim Tjernlund" <joakim.tjernlund@transmode.se> wrote:
> 
> > Looking at rtc-dev.c I don't see a MARJOR number assigned 
> to /dev/rtcN. Seems like
> > it is dynamically allocated to whatever major number that is free.
> > Is that the way it is supposed to be? How do I create a 
> static /dev/rtcN in my /dev
> > directory if the major number isn't fixed?
> > Maybe I am just missing something, feel free to correct me :)
> 
>  udev ;)
> 
>  the concept of static numbers is quite old...

Yes it is old, but is the old way unsupported now? I have an embedded target
which is using the old static /dev directory, do I need to make
it udev aware to use newer features like the rtc subsystem?

 Jocke

Re: NTP time sync

[Alessandro Zummo]

On Sun, 26 Nov 2006 22:37:10 +0100
"Joakim Tjernlund" <joakim.tjernlund@transmode.se> wrote:

> >  the concept of static numbers is quite old...
> 
> Yes it is old, but is the old way unsupported now? I have an embedded target
> which is using the old static /dev directory, do I need to make
> it udev aware to use newer features like the rtc subsystem?

 That can be a good option. You can also do
 a symlink to /dev/rtc0 in your boot scripts or simply
 upgrade your hwclock to a version that accepts
 the device as a parameter.

 The old /dev/rtc name is not supported on the new rtc subsystem.

 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it

Re: [Bulk] Re: NTP time sync

[David Brownell]

On Sunday 26 November 2006 2:53 pm, Alessandro Zummo wrote:
> On Sun, 26 Nov 2006 22:37:10 +0100
> "Joakim Tjernlund" <joakim.tjernlund@transmode.se> wrote:
> 
> > >  the concept of static numbers is quite old...
> > 
> > Yes it is old, but is the old way unsupported now? I have an embedded target
> > which is using the old static /dev directory, do I need to make
> > it udev aware to use newer features like the rtc subsystem?
> 
>  That can be a good option. 

And it's simple enough.  You might not even need to run "udevd"
if you don't have hotpluggable devices ... just the startup stuff,
which you might not need after the first boot.  (Since the set of
devices will be stable, /dev/* won't change, and you can speed up
system boot by that small delta.)

I certainly run udev on some small systems, with /sbin/hotplug as
appended.  Getting udev set up, and handling coldplug, is left as
an exercise for the reader.  :)

- Dave

#!/bin/ash
#
# "hotplug" initializes devices ... hardware drivers get modprobed and
# create class devices.  then later udev handles /dev node creation and
# invokes programs that make userspace aware of the new device node.
#
# install as /sbin/hotplug

if [ ! -d /sys ]
then
	exit 1
fi
cd /sys

if [ "$ACTION" = "add" -a "$SUBSYSTEM" = "mmc" ]
then
	# MMC doesn't support modalias yet, but this is
	# the only choice until we have SDIO support.
	MODALIAS=mmc_block
fi

if [ "$ACTION" = "add" -a -n "$MODALIAS" -a ! -L $DEVPATH/driver ]
then
	# most important subsystems now have $MODALIAS support:
	modprobe -q $MODALIAS
fi

if [ -n "$DEVPATH" ]
then
	/sbin/udevsend $1
fi