Re: ntp and hwclock
Followup-To:
On 2007-01-23, Andrei Popescu wrote:
> On Tue, 23 Jan 2007 09:53:22 -0800
> Andrew Sackville-West <andrew@farwestbilliards.com> wrote:
>
>> On Tue, Jan 23, 2007 at 05:38:30PM +0000, Oleg Verych wrote:
>> >
>> > I have set up clock in my Ericsson mobile phone more than 3 years
>> > ago. If drift exists, it is less that one second, after all.
sorry here -- less than one minute. 3+ years passed, i've never adjusted
munites, as i still see f.e. 11:04 on the phone, where news on TV or
radio are telling time.
>>
>> I was under the impression that mobile phone's sync their clocks over
>> the cellular network, but I may be wrong on that.
>
> AFAIK GSM has this option, if the provider supports it and you activate
> it on your phone.
Trick is, that i've set up phone's time to have +4 minutes of UTC. So, i
live in near future, that's the way i do ;) And my model (old, best 2001)
have that UNIX way of setting up of clock: main setup, timezone setup,
daylight setup. Last one, due to political influence, is set up accoding
to current state of law of particular country (apt-get install tzdata ;).
On Tue, Jan 23, 2007 at 04:23:39PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 23 Jan 2007, Oleg Verych wrote:
> > On Tue, Jan 23, 2007 at 03:12:45PM -0200, Henrique de Moraes Holschuh wrote:
> > > On Tue, 23 Jan 2007, Ken Heard wrote:
> > > > >Linux kernel updates CMOS (hardware clock) time every 11 minutes.
> > >
> > > Only when in ntp sync mode, AFAIK. Maybe the new RTC class lets one change
> > > this easily, but then the "CMOS RTC" port to the new RTC class ain't in
> > > Linux mainline yet.
> >
> > I think this is default, and it is not depend on new RTC subsystem,
> > Try to not to run /etc/init.d/hwclock*.sh on startup, and you will see,
> > that in-kernel clock is set up.
>
> Initialize system time from RTC at bootup != sync RTC every 11 minutes.
,-*- linux-source/Documentation/rtc.txt
|Also, if the kernel time is synchronized with an external source, the
|kernel will write the time back to the CMOS clock every 11 minutes. In
|the process of doing this, the kernel briefly turns off RTC periodic
|interrupts, so be aware of this if you are doing serious work. If you
|don't synchronize the kernel time with an external source (via ntp or
|whatever) then the kernel will keep its hands off the RTC, allowing you
|exclusive access to the device for your applications.
`-*-
A phrase "via ntp or whatever" + x86-64's bootup setup led me to
think, that this applies as "if the kernel time is synchronized with
an external source". Simple test showed me, that this isn't true.
Anyway, in-kernel time was made as more precise one comparing to any RTC,
CMOS. Two test points on-boot and on-shutdown is enough for PC, instead
that i've thought.
The CMOS update after 11 minutes in case of network synchronization, is
needed just to not to loose previous more or less valuable time-value.
Maybe now i've started to understand, why that was made and is wanted
to be moveed to userspace: to let userspace choose method of gaining
and storing precision.
> > > Plus low stability on the kernel clock sources in the presence of cpu freq
> > > changes, sleep to ram or to disk, spread-spectrum clock modulation, and general bogon activity.
> >
> > kernel + hardware bugs.
>
> kernel design + hardware design + bugs in both.
Intel case with ACPI, EFI (standards), buggy timers, counters (as with AMD
chips) led me to think, that in some cases kernel developers have
limited design decision. Vendors with BIOSes, tested to boot Offtopic
System is another major issue, Intel finally trying to deal with:
<http://www.linuxfirmwarekit.org/>
____
Reply to: