[SOLVED] Effect of adjusting the hardware clock on system time

hazel · 09-27-2020, 06:08 AM

My hardware clock runs slow so I decided to try the traditional solution and correct for drift in /etc/adjtime rather than use an ntp server. I did a drift adjustment over a period of about a week and now the clock runs correctly. But the system clock is still slow.

This is Slackware, so the time setting command is in rc.S:
/sbin/hwclock --utc --hctosys

According to the man page:

Quote:

hwclock --hctosys also uses the adjtime file data to compensate the value read from the Hardware Clock before using it to set the System Clock.

I read this as meaning that hwclock should use the data in the adjtime file to correct the raw clock time when setting the system clock just as it seems to be doing when showing the time directly. So what is going wrong?

michaelk · 09-27-2020, 07:13 AM

That is how I understand things should work. To be specific by slow do you mean there is an negative offset when the system clock is set or the system clock just runs slow?

The system clock could also drift. The only time the system clock is set is at boot time unless you have a cron job. Without ntp you should also tweak the system clock using adjtimex.

hazel · 09-27-2020, 07:46 AM

I'm not sure I understand that question. There is a negative offset in the file now because I ran hwclock yesterday with the update-drift option as described in the man page. Before, the offset was 0. Now when I run hwclock as root, it shows the same time as the clock on the wall. Here's a printout from hwclock if that helps:

Code:

# hwclock --debug
hwclock from util-linux 2.27.1
Using the /dev interface to the clock.
Last drift adjustment done at 1601141360 seconds after 1969
Last calibration done at 1601141360 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/09/27 12:42:58
Hw clock time : 2020/09/27 12:42:58 = 1601210578 seconds since 1969
Time since last adjustment is 69218 seconds
Calculated Hardware Clock drift is -233.357671 seconds
Sun 27 Sep 2020 13:42:57 BST  .069283 seconds

That matches the time on my electric wall clock. But the system time is two minutes behind.

michaelk · 09-27-2020, 07:56 AM

The hardware and system clock are totally separate. By default only at boot is the system clock set from the hardware clock. Have you used hwclock recently to set the system clock? If so is the system time still different?

hazel · 09-27-2020, 08:00 AM

That's the point which puzzles me. The boot script rc.S sets the system clock from the hardware clock (see my initial post) and I boot up every day. I haven't changed the time by hand using date. So how does the system clock come to be slow? Look at this:

Code:

# hwclock
Sun 27 Sep 2020 13:59:33 BST  .038633 seconds
root@bigboy:/etc/rc.d
# date
Sun 27 Sep 13:56:38 BST 2020
root@bigboy:/etc/rc.d

michaelk · 09-27-2020, 08:55 AM

The same offset at boot up? Will have to experiment when I get home.

onebuck · 09-27-2020, 09:40 AM

Hi,

Hazel, I use this to compare clocks ;

Code:

# date; hwclock -c
Sun Sep 27 09:36:25 CDT 2020
hw-time      system-time         freq-offset-ppm   tick
1601217386   1601217386.006221
1601217396   1601217396.006886                66      1
1601217406   1601217406.007207                49      0
1601217416   1601217416.007552                44      0
1601217426   1601217426.007913                42      0
1601217436   1601217436.008221                40      0
1601217446   1601217446.008547                39      0
1601217456   1601217456.008987                40      0
1601217466   1601217466.009401                40      0
1601217476   1601217476.009759                39      0
1601217486   1601217486.010125                39      0
1601217496   1601217496.010472                39      0
1601217506   1601217506.010861                39      0
1601217516   1601217516.011212                38      0

From man hwclock;

Quote:

-c, --compare
Periodically compare the Hardware Clock to the System Time and output the difference every 10 seconds. This will also print the
frequency offset and tick.

Seems to me the way to compare hwclock with system time.
Hope this helps.
Have fun & enjoy Slackware!

hazel · 09-27-2020, 10:27 AM

Code:

# hwclock -c|tee hwclock.out
hw-time      system-time         freq-offset-ppm   tick
1601220360   1601220185.745410
1601220369   1601220195.746385            111219   1112
1601220379   1601220205.747091             52720    527
1601220389   1601220215.747506             34555    346
1601220399   1601220225.747918             25705    257
1601220409   1601220235.748786             20477    205
1601220419   1601220245.749498             17018    170
^C

OK, now what do I do with it?

michaelk · 09-27-2020, 11:29 AM

By the default the hwclock should be updated when shutdown. If you reboot the computer, check the time in the bios then boot into the OS and compare the times. I would think that would tell how the correction is being applied.

onebuck · 09-27-2020, 01:28 PM

Hi,

By chance do you boot between different Gnu/Linux on this machine? If you do then how is the time setup for each. If you have UTC on one and local on the other then you may have issue with the kernel clock updating. When the local boots then the time differences would be different for the RTC from the UTC machine shutdown thus system time would certainly be different.

From your output for 'hwclock -c' you have drift that is greater than I would expect. So my suspicions would be a update issue. Do you have the 'hwclockd' running and attempt to NTP the time?

I'm just guessing and using past experiences but I would look at https://docs.slackware.com/howtos:ha...tem_local_time for some help with diagnosing.

rnturn · 09-27-2020, 10:26 PM

Quote:

Originally Posted by hazel

My hardware clock runs slow so I decided to try the traditional solution and correct for drift in /etc/adjtime rather than use an ntp server. I did a drift adjustment over a period of about a week and now the clock runs correctly. But the system clock is still slow.

Any reason why NTP is not being used? Somewhere on your motherboard is a crystal that is the source of the clock signals. Crystals make fairly lousy frequency standards---they drift all over the place. That's a big reason for NTP. Setting the time during system boot might work okay for a laptop that's booted daily (or several times during the day) but for a server with long uptimes, it's not a good way to keep time. I've seen servers booted after scheduled data center downtime whose clocks, presumably in very close agreement following the use of something like "ntpdate" to set the date/time during system boot, differed by a couple minutes after being up for a long period---enough of a difference that it was affecting applications.

NTP doesn't exactly burden a system. Just curious but what would be a reason to skip running it?

cordx · 09-28-2020, 01:42 AM

there is a section in the hwclock man page that describes a way to keep time without external synchronization:

Quote:

DATE-TIME CONFIGURATION
Keeping Time without External Synchronization
This discussion is based on the following conditions:

· Nothing is running that alters the date-time clocks, such as ntpd(1)
or a cron job.

· The system timezone is configured for the correct local time. See
below, under POSIX vs 'RIGHT'.

· Early during startup the following are called, in this order:
adjtimex --tick value --frequency value
hwclock --hctosys

· During shutdown the following is called:
hwclock --systohc

* Systems without adjtimex may use ntptime.
...

hazel · 09-28-2020, 05:49 AM

Quote:

Originally Posted by michaelk

By the default the hwclock should be updated when shutdown. If you reboot the computer, check the time in the bios then boot into the OS and compare the times. I would think that would tell how the correction is being applied.

OK Here are today's figures:

BIOS time at boot: 10:32:10
hwclock at login: 11:33
date at login: 11:30

I consider the first two figures to be compatible, given that I took a little while to get the boot going again after diverting into the BIOS. The system time given by the date command is definitely slow.

@onebuck. Yes, I booted LFS during last week in order to dump Slackware but that also assumes a UTC clock. If it was a mixup between two distros about the clock regime, you would get a difference of an hour, not two minutes. I remember once having that problem and it took me quite a while to troubleshoot it. And no, I don't have a clock daemon. I didn't even know that existed until I read your post.

@rnturn. I'm just curious to see if I can do it the traditional way. If I was running a server, I certainly would use ntpd but I'm just a hobbyist.

@cordx. That method probably wouldn't work for me because I do occasionally boot other systems.

hazel · 09-28-2020, 08:29 AM

Curiouser and curiouser. I just ran hwclock --adjust and now my system clock tells the same time as the hardware clock. The problem is: both are now slow according to the wall clock.

michaelk · 09-28-2020, 08:36 AM

Have you looked at the adjtime file to check the drift rate? The value is seconds per day and it just looks like it is high.

Quote:

Hw clock time : 2020/09/27 12:42:58 = 1601210578 seconds since 1969
Time since last adjustment is 69218 seconds
Calculated Hardware Clock drift is -233.357671 seconds