Updating RTC with date command

Updating RTC with date command

[Nori, Soma Sekhar]

Hi,

I am trying to add RTC (ds1338) support to 2.6.10 mips kernel
running on my 4kec board.

I have populated the rtc_{get|set}_time and rtc_set_mmss pointers 
and the date command shows the time correctly (as read from the RTC).

However, when I try to update the time using date -s <time string> 
the RTC does not get updated. (shows the old time when I boot-up again)

In arch\mips\kernel\time.c the timer_interrupt calls rtc_set_mmss,
but that call is made only when STA_UNSYNC is _not_ set in time_status
variable. do_settimeofday/sys_stime _set_ this flag so the timer 
interrupt does not call rtc_set_mmss. 	

In all, I could not figure out any other invocation of rtc_set_time or 
rtc_set_mmss which could be setting the time in my case.

Can somebody please help me understand how the RTC is supposed to be
updated after user changes the time using the date command?

Thanks,
Sekhar Nori

Updating RTC with date command

[Nori, Soma Sekhar]

Hi,

I am trying to add RTC (ds1338) support to 2.6.10 mips kernel
running on my 4kec board.

I have populated the rtc_{get|set}_time and rtc_set_mmss pointers 
and the date command shows the time correctly (as read from the RTC).

However, when I try to update the time using date -s <time string> 
the RTC does not get updated. (shows the old time when I boot-up again)

In arch\mips\kernel\time.c the timer_interrupt calls rtc_set_mmss,
but that call is made only when STA_UNSYNC is _not_ set in time_status
variable. do_settimeofday/sys_stime _set_ this flag so the timer 
interrupt does not call rtc_set_mmss. 	

In all, I could not figure out any other invocation of rtc_set_time or 
rtc_set_mmss which could be setting the time in my case.

Can somebody please help me understand how the RTC is supposed to be
updated after user changes the time using the date command?

Thanks,
Sekhar Nori

Re: Updating RTC with date command

[Ralf Baechle]

On Tue, Jul 19, 2005 at 03:34:01PM +0530, Nori, Soma Sekhar wrote:

> I am trying to add RTC (ds1338) support to 2.6.10 mips kernel
> running on my 4kec board.
> 
> I have populated the rtc_{get|set}_time and rtc_set_mmss pointers 
> and the date command shows the time correctly (as read from the RTC).
> 
> However, when I try to update the time using date -s <time string> 
> the RTC does not get updated. (shows the old time when I boot-up again)
> 
> In arch\mips\kernel\time.c the timer_interrupt calls rtc_set_mmss,
> but that call is made only when STA_UNSYNC is _not_ set in time_status
> variable. do_settimeofday/sys_stime _set_ this flag so the timer 
> interrupt does not call rtc_set_mmss. 	
> 
> In all, I could not figure out any other invocation of rtc_set_time or 
> rtc_set_mmss which could be setting the time in my case.
> 
> Can somebody please help me understand how the RTC is supposed to be
> updated after user changes the time using the date command?

Not at all.  Try man hwclock.

  Ralf

Re: Updating RTC with date command

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

On Tue, 2005-07-19 10:31:10 -0400, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Tue, Jul 19, 2005 at 03:34:01PM +0530, Nori, Soma Sekhar wrote:
> > However, when I try to update the time using date -s <time string> 
> > the RTC does not get updated. (shows the old time when I boot-up again)

Right, expected. date -s  sets the time of the running system, not the
system's HW time.

> > In arch\mips\kernel\time.c the timer_interrupt calls rtc_set_mmss,
> > but that call is made only when STA_UNSYNC is _not_ set in time_status
> > variable. do_settimeofday/sys_stime _set_ this flag so the timer 
> > interrupt does not call rtc_set_mmss. 	

Right. HW clock updating is somewhat supposed to work IFF ntp is
running.

> > Can somebody please help me understand how the RTC is supposed to be
> > updated after user changes the time using the date command?
> 
> Not at all.  Try man hwclock.

hwclock is the userspace utility to manually once set the time. In
normal operation, this should only be called _once_, after the system is
switched on for the very first time.

During lifetime, ntpd should execute and thus the system's current time
will be written to the HW clock every now and then. Additionally, most
distributions seem to also update the HW clock at system shutdown time.

So the correct solution to your problem is to either shutdown once
(workaround) or keep ntpd running (the solution[tm]).

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Updating RTC with date command

[Maciej W. Rozycki]

On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:

> hwclock is the userspace utility to manually once set the time. In
> normal operation, this should only be called _once_, after the system is
> switched on for the very first time.

 Well, `hwclock' should normally be used to update the RTC every time 
after a manual system clock update.

> During lifetime, ntpd should execute and thus the system's current time
> will be written to the HW clock every now and then. Additionally, most

 Note that ntpd only updates minutes and seconds and then only if the 
difference is small -- to account for the existence of time zones and a 
system-specific relation between the time recoreded by the system and one 
handled by the RTC.  Also the feature is broken by design -- ntpd 
shouldn't do that at all in principle and in practice it leads to the 
system time being corrupted on some machines using an RTC interrupt for 
the system timer tick.

> distributions seem to also update the HW clock at system shutdown time.

 Which is where it should really happen.

> So the correct solution to your problem is to either shutdown once
> (workaround) or keep ntpd running (the solution[tm]).

 I think you've got the figures reversed (well, it's useful to have ntpd 
running, but it should not fiddle with the RTC).

  Maciej

Re: Updating RTC with date command

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

On Tue, 2005-07-19 16:06:21 +0100, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:
> 
> > hwclock is the userspace utility to manually once set the time. In
> > normal operation, this should only be called _once_, after the system is
> > switched on for the very first time.
> 
>  Well, `hwclock' should normally be used to update the RTC every time 
> after a manual system clock update.

Which of course should only be done once. Ever :)

> > During lifetime, ntpd should execute and thus the system's current time
> > will be written to the HW clock every now and then. Additionally, most
> 
>  Note that ntpd only updates minutes and seconds and then only if the 
> difference is small -- to account for the existence of time zones and a 
> system-specific relation between the time recoreded by the system and one 
> handled by the RTC.  Also the feature is broken by design -- ntpd 
> shouldn't do that at all in principle and in practice it leads to the 
> system time being corrupted on some machines using an RTC interrupt for 
> the system timer tick.

Aren't we expected to keep UTC time inside the HW clock? So there's no
problem with timezones.  Also, if your timer interrupt source it that
broken that ntpd cannot track it, then you're having more servere
problems...

> > distributions seem to also update the HW clock at system shutdown time.
> 
>  Which is where it should really happen.

I disagree. IFF there's a known good time, it's acceptable to write it
into a backing HW clock. In case there isn't (any longer), it's probably
better to not write to the HW clock at all. Probably it's contents is
better than a wrongly manually adjusted local date setting...

I do trust ntpd, but do I trust someone who looks at it's watch?

> > So the correct solution to your problem is to either shutdown once
> > (workaround) or keep ntpd running (the solution[tm]).
> 
>  I think you've got the figures reversed (well, it's useful to have ntpd 
> running, but it should not fiddle with the RTC).

Well, I stated my oppinion. Maybe ntpd shouldn't set the clock (or make
the kernel set it internally), but for sure I don't want the HW clock
being set by hand (except very first power-up of the system) and by no
means if local time came up from a manual process.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
fuer einen Freien Staat voll Freier Buerger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Updating RTC with date command

[Maciej W. Rozycki]

On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:

> >  Well, `hwclock' should normally be used to update the RTC every time 
> > after a manual system clock update.
> 
> Which of course should only be done once. Ever :)

 Well, depending on whether the system is networked or not.  If it is, 
it's not needed at all as you fetch the initial setting over NTP, too.  If 
it's not, then unfortunately it's needed every time you notice the clock 
has skewed too much.

> >  Note that ntpd only updates minutes and seconds and then only if the 
> > difference is small -- to account for the existence of time zones and a 
> > system-specific relation between the time recoreded by the system and one 
> > handled by the RTC.  Also the feature is broken by design -- ntpd 
> > shouldn't do that at all in principle and in practice it leads to the 
> > system time being corrupted on some machines using an RTC interrupt for 
> > the system timer tick.
> 
> Aren't we expected to keep UTC time inside the HW clock? So there's no

 It's a good idea, but whether it's feasible or not is unfortunately 
system-specific.

> problem with timezones.  Also, if your timer interrupt source it that
> broken that ntpd cannot track it, then you're having more servere
> problems...

 Huh?  The time source is correct if let to run freely, but modifying the 
time stored in RTC may disturb it.  This is e.g. the case with the 
Motorola MC146818 and its clones which are rather common chips -- any 
system using their periodic interrupt for the system clock tick suffers 
from this problem.

> > > distributions seem to also update the HW clock at system shutdown time.
> > 
> >  Which is where it should really happen.
> 
> I disagree. IFF there's a known good time, it's acceptable to write it
> into a backing HW clock. In case there isn't (any longer), it's probably
> better to not write to the HW clock at all. Probably it's contents is
> better than a wrongly manually adjusted local date setting...

 Something has to preserve the clock across reboots and power-offs.  
Which of the sources is to be trusted more is a matter of a local policy 
and neither the kernel nor tools should force any particular one.

> I do trust ntpd, but do I trust someone who looks at it's watch?

 Well, I do trust myself ultimately...

> > > So the correct solution to your problem is to either shutdown once
> > > (workaround) or keep ntpd running (the solution[tm]).
> > 
> >  I think you've got the figures reversed (well, it's useful to have ntpd 
> > running, but it should not fiddle with the RTC).
> 
> Well, I stated my oppinion. Maybe ntpd shouldn't set the clock (or make
> the kernel set it internally), but for sure I don't want the HW clock
> being set by hand (except very first power-up of the system) and by no
> means if local time came up from a manual process.

 If ntpd has been running with a good reference it must have disciplined 
the system clock, so it should have a smaller drift than the RTC.  So it 
should be safe to store the former into the latter at a shutdown (but 
that's a policy).  Otherwise nothing can be told about both clocks and the 
system's administrator should decide.  In the end I think the decision 
should be left up to the administrator in all cases.

  Maciej

Re: Updating RTC with date command

[Jan-Benedict Glaw]

[-- Attachment #1.1: Type: text/plain, Size: 4513 bytes --]

On Tue, 2005-07-19 17:40:48 +0100, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote:
> > >  Note that ntpd only updates minutes and seconds and then only if the 
> > > difference is small -- to account for the existence of time zones and a 
> > > system-specific relation between the time recoreded by the system and one 
> > > handled by the RTC.  Also the feature is broken by design -- ntpd 
> > > shouldn't do that at all in principle and in practice it leads to the 
> > > system time being corrupted on some machines using an RTC interrupt for 
> > > the system timer tick.
> > 
> > Aren't we expected to keep UTC time inside the HW clock? So there's no
> 
>  It's a good idea, but whether it's feasible or not is unfortunately 
> system-specific.

The base year may change, but for the rest, aren't there Windows boxes
on one hand (using local time in RTC) and all other OSses using UTC in
there?

> > problem with timezones.  Also, if your timer interrupt source it that
> > broken that ntpd cannot track it, then you're having more servere
> > problems...
> 
>  Huh?  The time source is correct if let to run freely, but modifying the 
> time stored in RTC may disturb it.  This is e.g. the case with the 
> Motorola MC146818 and its clones which are rather common chips -- any 
> system using their periodic interrupt for the system clock tick suffers 
> from this problem.

The main problem is that there are several time sources in a modern
machine, and these are somewhat unsynchronized. Pick one and correct it,
the others will look fucked up. ...or keep correcting them all. There's
just a difference of usage. Some time sources are used only every now
and then (like the HW clock), others all the time (like the calculated
time, tick'ed by the timer interrupt) or only in very specific
situations (in-processor cycle counters). Some systems won't even
generate timer interrupts at all, but always ask specific hardware
whenever a timestamp is needed.

What I care most about is that there's a well-behaving time being
returned by time() or gettimeofday(), usually generated (on PeeCees)
from the timer interrupt.  This should be corrected to be as good as
possible, usually through the help of ntpd.

The long-term time sources (like the HW clock) should be updated, too,
but it's contents only needs to be correct any now and then; for sure,
there isn't such a high need for strong monotony as there is in the
gettimeofday() interface. Thus, updating it every 11 minutes from the
system time IFF it's properly sync'ed seems reasonable to me. For sure,
I don't want a bad time being written to it. Maybe it would be wise to
have a "last known-good time" timestamp for it, though, to refuse using
it IFF it's a clock suspected to be horribly wrong (like the famous
146818)...

>  Something has to preserve the clock across reboots and power-offs.  
> Which of the sources is to be trusted more is a matter of a local policy 
> and neither the kernel nor tools should force any particular one.

You're right on this, but keep in mind that some machines don't rely on
a RTC at all. They ask you to enter current time+date manually and will
try to sync it with a better time source some time later.

> > I do trust ntpd, but do I trust someone who looks at it's watch?
> 
>  Well, I do trust myself ultimately...

/* No comment on this :-)  */

>  If ntpd has been running with a good reference it must have disciplined 
> the system clock, so it should have a smaller drift than the RTC.  So it 
> should be safe to store the former into the latter at a shutdown (but 
> that's a policy).  Otherwise nothing can be told about both clocks and the 
> system's administrator should decide.  In the end I think the decision 
> should be left up to the administrator in all cases.

With "modern" RTCs, even disciplining them isn't easy. Ever kept an eye
on the frequency value? Depending on your mainboard's quality, you may
use it as a quite precise thermometer... Link the attached script into
your /etc/munin/plugins/ and have fun :)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #1.2: local-ntp_frequency --]
[-- Type: text/plain, Size: 569 bytes --]

#!/bin/sh

export PATH=/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin:$PATH

case "$1" in
	autoconf)
		echo no
		;;
	config)
		echo 'graph_title NTP frequency'
		echo 'graph_vlabel freq'
		echo 'graph_category NTP'
		echo 'graph_info This graph shows the frequency (mis-clocking) of the local timer source.'
		echo 'graph_scale no'
		echo 'frequency.label Frequency'
		echo 'frequency.info Current Frequency.'
		;;
	*)
		FREQUENCY="`echo rv | ntpq -n | tr ',' $'\n' | grep freq | cut -f 2 -d '='`"
		echo "frequency.value ${FREQUENCY}"
		;;
esac

exit 0


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]