Re: [gentoo-user] hwclock <--> sysclock and the ntp-client

[Michael Mol]

On Feb 6, 2012 7:00 PM, <meino.cramer@×××.de> wrote:
>
> Michael Mol <mikemol@×××××.com> [12-02-06 19:56]:
> > On Mon, Feb 6, 2012 at 1:39 PM,  <meino.cramer@×××.de> wrote:
> > > Michael Mol <mikemol@×××××.com> [12-02-06 19:20]:
> > >> On Mon, Feb 6, 2012 at 12:51 PM,  <meino.cramer@×××.de> wrote:
> > >> > Hi,
> > >> >
> > >> > to get the correct system time I use ntp-client in the boot
process.
> > >> > Furthermore in /etc/conf.d/hwclock I set:
> > >> >
> > >> >    # Set CLOCK to "UTC" if your Hardware Clock is set to UTC (also
known as
> > >> >    # Greenwich Mean Time).  If that clock is set to the local
time, then
> > >> >    # set CLOCK to "local".  Note that if you dual boot with
Windows, then
> > >> >    # you should set it to "local".
> > >> >    clock="UTC"
> > >> >
> > >> >    # If you want to set the Hardware Clock to the current System
Time
> > >> >    # (software clock) during shutdown, then say "YES" here.
> > >> >    # You normally don't need to do this if you run a ntp daemon.
> > >> >    clock_systohc="YES"
> > >> >
> > >> >    # If you want to set the system time to the current hardware
clock
> > >> >    # during bootup, then say "YES" here. You do not need this if
you are
> > >> >    # running a modern kernel with CONFIG_RTC_HCTOSYS set to y.
> > >> >    # Also, be aware that if you set this to "NO", the system time
will
> > >> >    # never be saved to the hardware clock unless you set
> > >> >    # clock_systohc="YES" above.
> > >> >    clock_hctosys="NO"
> > >> >
> > >> >    # If you wish to pass any other arguments to hwclock during
bootup,
> > >> >    # you may do so here. Alpha users may wish to use --arc or
--srm here.
> > >> >    clock_args=""
> > >> >
> > >> > In the kernel config file I had set:
> > >> >
> > >> >    CONFIG_RTC_HCTOSYS=y
> > >> >    CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
> > >> >
> > >> > I would exspect that after a reboot of the system which system
time is
> > >> > correctly set via ntp-client that the hwclock and system time only
> > >> > differ in a small amount of time.
> > >> >
> > >> > But:
> > >> > solfire:/home/mccramer>hwclock
> > >> > Mon Feb  6 19:05:11 2012  -0.172569 seconds
> > >> > solfire:/home/mccramer>date
> > >> > Mon Feb  6 18:49:37 CET 2012
> > >> > solfire:/home/mccramer>
> > >>
> > >> I don't know the CET tz, but I can see that the minutes don't match
> > >> up. I assume you rand the two commands within seconds of each other.
> > >> Is this true immediately after bootup, or does it take a while to get
> > >> that far off? It could be that your hardware clock is drifting, and
> > >> the system won't reset it until it goes to shutdown.
> > >>
> > >> --
> > >> :wq
> > >>
> > >
> > > Hi Michael,
> > > thank you for your reply.
> > > I set the configuration as mentioned above and booted twice with about
> > > five minutes wait.
> > > The commands were executed within seconds, yes.
> > > All hardware clocks drifts, but this is not the problem.
> > > The problem is that the hardware clock is not set to the system time
> > > in contradiction to what I think the comments in the config are
> > > saying.
> > >
> > > How can I fix that?
> >
> > I don't really know. Are you sure that rtc0 corresponds to your
> > hardware clock device? Does setting "clock_hctosys" to YES have any
> > effect?
> >
> > Is this in some kind of virtual-machine or hypervised environment
> > where something may be blocking the OS from setting the hardware
> > clock?
> >
> > --
> > :wq
> >
>
> It is set
>
> lrwxrwxrwx 1 root root       4 2012-02-07 00:52 /dev/rtc -> rtc0
> crwxrwx--- 1 root audio 254, 0 2012-02-07 00:52 /dev/rtc0
>
> and it is the only device of its kind.
>
> As I wrote I am using ntp_client for setting my system time while
> booting up.
> So reagrdless wheter I am setting clock_hctosys I am alway getting
> the correct system time later in the bootprocess via ntp.

Sure. My question was more geared toward specifically obtaining information
about your hardware clock, which you probed with the hwclock command. You
insist your hardware clock isn't being updated, but I have insufficient
data to verify that, or even get a feel for the behavior of your system.
*Obviously* all hardware clocks drift, but I was wondering if your hardware
clock was drifting notably rapidly. I don't know at what interval the
hardware clock would normally be updated by the kernel, or what constitutes
'continuous' in that context.

Timestamps along with the commands and for notable events, such as when
ntpclient ran during bootup and when the system shut down, would be useful.