Re: Updating RTC with date command

[Jan-Benedict Glaw <jbglaw@lug-owl.de>]

[-- 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 --]