NTP time sync

 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

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:

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

On Wed, 22 Nov 2006 11:55:23 -0800
David Brownell [off-list ref] wrote:

quoted

 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

On Wed, 22 Nov 2006 19:51:53 +0000
Russell King [off-list ref] wrote:

quoted

 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

On Wed, Nov 22, 2006 at 09:23:55PM +0100, Alessandro Zummo wrote:

On Wed, 22 Nov 2006 11:55:23 -0800
David Brownell [off-list ref] wrote:
=20

quoted

quoted

=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

[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

On Thu, 2006-11-23 at 11:54 +0100, Andi Kleen wrote:

quoted

[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

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

-----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:

quoted

Couldn't we have a transition period by making the kernel 

not rely on

quoted

interrupts ? if the NTP irq code just triggers a work 

queue, then all of

quoted

a sudden, all of the RTC drivers can be used and the 

latency is small.

quoted

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

On Sun, 26 Nov 2006 12:04:54 +0100
"Joakim Tjernlund" [off-list ref] 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

-----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" [off-list ref] wrote:

quoted

Looking at rtc-dev.c I don't see a MARJOR number assigned 

to /dev/rtcN. Seems like

quoted

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

quoted

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

On Sun, 26 Nov 2006 22:37:10 +0100
"Joakim Tjernlund" [off-list ref] wrote:

quoted

 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

On Sunday 26 November 2006 2:53 pm, Alessandro Zummo wrote:

On Sun, 26 Nov 2006 22:37:10 +0100
"Joakim Tjernlund" [off-list ref] wrote:

quoted

quoted

 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