comp.protocols.time.ntp
Discussion complète de l'article :
Linux 11-minute mode (RTC update)

Date

Sujet

From


03-04-2008

     Linux 11-minute mode (RTC update)

Noob

04-04-2008

         Re: Linux 11-minute mode (RTC update)

Serge Bets

04-04-2008

             Re: Linux 11-minute mode (RTC update)

Noob


Article : 27425
Date : 03-04-2008
From : Noob
Sujet : Linux 11-minute mode (RTC update)

Hello everyone,

I run Linux kernel 2.6.22.1-rt9 and ntpd 4.2.4p0

# adjtimex --print
mode: 0
offset: 77
frequency: -1309904
maxerror: 493576
esterror: 50
status: 1
time_constant: 6
precision: 1
tolerance: 33554432
tick: 10000
raw time: 1207230744s 183249us = 1207230744.183249

In my setup, STA_UNSYNC (0x0040, clock unsynchronized) is 0.

Thus, ntp_synced() returns 1.

Thus the kernel should write the system time to the RTC every
11 minutes; but it does not.

The relevant code is in sync_cmos_clock()

http://lxr.linux.no/linux/kernel/time/ntp.c#L188

I've added several printk() to this function, and it appears
that it is never called.

The relevant timer is defined with the following macro.

static DEFINE_TIMER(sync_cmos_timer, sync_cmos_clock, 0, 0);

which expands to

static struct timer_list sync_cmos_timer =
{
.function = sync_cmos_clock,
.expires = 0,
.data = 0,
.base = &boot_tvec_bases
};

The problem seems to be that this timer is never armed, to bootstrap
the process. It seems there should be a call to mod_timer() somewhere.

do_adjtimex() calls notify_cmos_timer() unconditionally.

static void notify_cmos_timer(void)
{
if (no_sync_cmos_clock)
mod_timer(&sync_cmos_timer, jiffies + 1);
}

What are the semantics of notify_cmos_timer?
What is it supposed to do?

And what is 'no_sync_cmos_clock' supposed to mean?
/* Disable the cmos update - used by virtualization and embedded */
int no_sync_cmos_clock __read_mostly;
Why would we (re)arm the timer when 'no_sync_cmos_clock' is true?

I'd be grateful for anyone sharing their knowledge.

Regards.

Posez vos questions, réponses et remarques sur les forums de FrameIP


Article : 27442
Date : 04-04-2008
From : Serge Bets
Sujet : Re: Linux 11-minute mode (RTC update)

Hello,

On Thursday, April 3, 2008 at 16:25:17 +0200, Noob wrote:

> STA_UNSYNC (0x0040, clock unsynchronized) is 0. [...] Thus the kernel
> should write the system time to the RTC every 11 minutes; but it does
> not.

Fine! Don't touch anything, happy man, or it might well "tomber en
marche". Real men don't want the eleven-minutes mode. It is not only
extremely inaccurate by itself, but it also steps on the toes of those
tools that are able to manage the RTC properly.

I previously posted some figures, comparing the accuracy of writing the
RTC (not counting drift). Mean offset and dispersion:

- eleven-minutes mode: -2150 µs +-5000
- hwclock util-linux-ng 2.13.1: -2500 µs +-170
- hwclock 2.32 from BJH: 0 µs +-10

Furthermore both hwclocks are able to evaluate and compensate the drift
of the RTC. The eleven-minutes mode cannot do that, and instead it can
perturbate hwclock's calculations.


Serge.
--
Serge point Bets arobase laposte point net

Posez vos questions, réponses et remarques sur les forums de FrameIP


Article : 27443
Date : 04-04-2008
From : Noob
Sujet : Re: Linux 11-minute mode (RTC update)

Serge Bets wrote:

> Noob wrote:
>
>> STA_UNSYNC (0x0040, clock unsynchronized) is 0. [...] Thus the kernel
>> should write the system time to the RTC every 11 minutes; but it does
>> not.
>
> Fine! Don't touch anything, happy man, or it might well "tomber en
> marche".

Hello Serge, I was hoping you'd comment!

If I don't want the kernel to update the RTC, I can always undef
CONFIG_GENERIC_CMOS_UPDATE.

> Real men don't want the eleven-minutes mode.

:-)

> It is not only extremely inaccurate by itself, but it also steps on
> the toes of those tools that are able to manage the RTC properly.

Our equipment is supposed to run 24/7 for months / years.
I need to keep the RTC synchronized, in case of power failure.

Do you believe that running hwclock --systohc periodically is better
than using the kernel's 11-minute mode?

> I previously posted some figures, comparing the accuracy of writing the
> RTC (not counting drift). Mean offset and dispersion:
>
> - eleven-minutes mode: -2150 µs +-5000
> - hwclock util-linux-ng 2.13.1: -2500 µs +-170
> - hwclock 2.32 from BJH: 0 µs +-10

Point taken.

( I use http://giraffe-data.com/software/about_hwclock.html )

If I use hwclock to update the RTC, how often should I do it?

What do you think about the following script?

while true
do
sleep 660 # or some other value?
hwclock --utc --systohc
done

> Furthermore both hwclocks are able to evaluate and compensate the drift
> of the RTC. The eleven-minutes mode cannot do that, and instead it can
> perturbate hwclock's calculations.

Is the crystal of the RTC supposed to be more stable than the crystal
of the CPU?

Regards.

Posez vos questions, réponses et remarques sur les forums de FrameIP




mot clé : minute comp update mode 11 ipv6 voip tcpip protocols linux ntp ip time rtc ipv4 vpn

Copyright © 2003-2010 FrameIP TcpIP. Tous droits réservés. Les marques et marques commerciales mentionnées appartiennent à leurs propriétaires respectifs. L'utilisation de ce site Web TcpIP implique l'acceptation des conditions d'utilisation et du règlement sur le respect de la vie privée.
Sécurité entreprise Comparatif Adsl SSII Reseaux Sécurité Test ADSL