On Feb 6, 2012 7:00 PM, <[email protected]> wrote: > > Michael Mol <[email protected]> [12-02-06 19:56]: > > On Mon, Feb 6, 2012 at 1:39 PM, <[email protected]> wrote: > > > Michael Mol <[email protected]> [12-02-06 19:20]: > > >> On Mon, Feb 6, 2012 at 12:51 PM, <[email protected]> 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.
