Solved The system clock is falling behind

T

tks

Good time. Sorry for my english. I have.
Code: 
 # uname -a
FreeBSD bsd.tks 11.1-BETA3 FreeBSD 11.1-BETA3 #0 r320251: Fri Jun 23 02:31:05 UTC 2017     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
and Intel Server Board S5000PARL.
The system clock is periodically lagging behind.
Code: 
# date
Fri Jun 30 07:48:56 MSK 2017
Although the right time.
Code: 
 % date
Fri Jun 30 09:31:42 MSK 2017
Service ntpd stops working. Sometimes when ntpd is running, time lags behind.
What I did.
Changed the battery on the motherboard.Installed from ports ntpd. Delete port ntpd.Changed the value:
kern.timecounter.hardware:

Code: 
# dmesg | grep Timecounter
Timecounter "TSC" frequency 1995044082 Hz quality 1000
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "HPET" frequency 14318180 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounters tick every 1.000 msec

Code: 
# sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC
This did not bring change.
Code: 
 # ntpdate pool.ntp.org
30 Jun 09:47:57 ntpdate[30838]: step time server 45.33.48.4 offset 6069.178468 sec
# date
Fri Jun 30 09:49:02 MSK 2017
# service ntpd start
Starting ntpd.
# cat /var/log/ntp.log
30 Jun 09:49:44 ntpd[31143]: Listen and drop on 0 v6wildcard [::]:123
30 Jun 09:49:44 ntpd[31143]: Listen and drop on 1 v4wildcard 0.0.0.0:123
30 Jun 09:49:44 ntpd[31143]: Listen normally on 2 em0 192.168.1.11:123
30 Jun 09:49:44 ntpd[31143]: Listen normally on 3 lo0 [::1]:123
30 Jun 09:49:44 ntpd[31143]: Listen normally on 4 lo0 [fe80::1%3]:123
30 Jun 09:49:44 ntpd[31143]: Listen normally on 5 lo0 127.0.0.1:123
30 Jun 09:49:44 ntpd[31143]: Listening on routing socket on fd #26 for interface updates
30 Jun 09:49:45 ntpd[31143]: Soliciting pool server 108.61.56.35
30 Jun 09:49:46 ntpd[31143]: Soliciting pool server 216.218.254.202
30 Jun 09:49:47 ntpd[31143]: Soliciting pool server 80.127.152.30
30 Jun 09:49:48 ntpd[31143]: Soliciting pool server 96.126.105.86
30 Jun 09:53:08 ntpd[31143]: Soliciting pool server 46.8.40.31
Code: 
ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.freebsd.pool. .POOL.          16 p    -   64    0    0.000    0.000   0.000
-lithium.constan 18.26.4.105      2 u   19   64  377  120.699    1.710   5.339
*clock.sjc.he.ne .CDMA.           1 u   23   64  377  180.945   -0.086   7.117
+aardbei.vanderz 131.211.8.244    2 u   11   64  377   57.812   -0.174   1.194
-mail.coldnortha 132.246.11.231   2 u   19   64  377  123.033    1.263   2.002
+46.8.40.31 (n2. 89.109.251.24    2 u   14   64  377   46.278   -2.719   0.939
After a while begins to lag behind.
What can I do to correct?
If I expressed myself incomprehensibly, my poor knowledge of the language is to blame for this.))
 
Now check if you have defined a driftfile in /etc/ntp.conf. There should be something like
Code: 
driftfile /var/db/ntpd.drift
Check if such file exists. If not you need to create it like this
echo "0" > /var/db/ntpd.drift
Restart ntpd. The value will be changed by ntpd thereafter.
 
  • Thanks
Reactions: tks
File exist.
Code: 
# cat /etc/ntp.conf | grep drift
# The driftfile is by default /var/db/ntpd.drift,
Code: 
# ls /var/db/ | grep ntp
drwx------   2 root      wheel        2B Apr 20 08:43 ntp
-rw-r--r--   1 root      wheel        7B Jun 30 10:49 ntpd.drift
-rw-r--r--   1 root      wheel       10K Mar 20 21:53 ntpd.leap-seconds.list
Code: 
# ps aux | grep ntp
root     31143   0.0  0.2  20696  12604  -  Ss   09:51       0:00.44 /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift
root     44489   0.0  0.0  14828   2492  0  S+   12:45       0:00.00 grep ntp
 
Ok, now try how the default Timecounter (not modified) is working and if the huge offset is gone.
Debugging ntp is a little time consuming as one needs to monitor over time if things are working.
Also important is not modifying too much at a time in the configuration as it would be difficult to determine what has helped.

So if, and only if the problem still persists try the ACPI timecounter.

To make changes persistent over reboots you need to add to /etc/sysctl.conf
Code: 
kern.timecounter.hardware=ACPI-fast

Give feedback after some monitoring time.
 
  • Thanks
Reactions: tks
I tried all timecounter values, "TSC", "i8254", "HPET", "ACPI-fast".
The problem persisted.
I'll try again, and watch again
 
Is your FreeBSD install running inside a virtual machine?

Did you add this to your /etc/rc.conf?

Code: 
ntpd_sync_on_start="YES"
 
  • Thanks
Reactions: tks
ntpd_sync_on_start="YES" sets the "-g" flag on ntpd, allowing for a large time adjustment when the server is started.

After adding it to rc.conf you should restart the server for it to take effect.
 
  • Thanks
Reactions: tks
Added and restart ntpd.
Code: 
# cat /etc/rc.conf | grep ntpd
ntpd_enable="YES"
ntpd_sync_on_start="YES"
Thanks for reply.
 
Good time. Today.
Code: 
 # date
Sat Jul  1 07:16:54 MSK 2017
Real time
Code: 
% date
Sat Jul  1 09:04:31 MSK 2017
Code: 
# service ntpd status
ntpd is not running.
Code: 
# tail -5 /var/log/ntp.log
 1 Jul 03:57:45 ntpd[81500]: Soliciting pool server 195.3.254.2
 1 Jul 03:57:46 ntpd[81500]: Soliciting pool server 78.36.11.161
 1 Jul 03:57:47 ntpd[81500]: Soliciting pool server 85.21.78.8
 1 Jul 03:57:48 ntpd[81500]: Soliciting pool server 213.141.154.170
 1 Jul 03:57:49 ntpd[81500]: Soliciting pool server 46.254.216.9
 
Your times are all over the place. With a diff of >1000sec it should be sending a panic to system logs and kill ntpd, which it looks like its doing.

ntpd()

per the above;

"
if ntpd detects that the time on the host is more than 1000s from
the server time, ntpd assumes something must be terribly wrong and the
only reliable action is for the operator to intervene and set the clock
by hand. (Reasons for this include there is no TOY chip, or its battery
is dead, or that the TOY chip is just of poor quality.) This causes ntpd
to exit with a panic message to the system log. The -g option overrides
this check and the clock will be set to the server time regardless of the
chip time (up to 68 years in the past or future -- this is a limitation
of the NTPv4 protocol). However, and to protect against broken hardware,
such as when the CMOS battery fails or the clock counter becomes defec-
tive, once the clock has been set an error greater than 1000s will cause
ntpd to exit anyway.
"

kill the service and restart with the -g flag.
DO NOT use -x, itll take 150days to skew to the correct time if I'm mathing right.

Did you manually set your ntp servers from your ntpq in your original post to /etc/ntp.conf?
poll them with sntp and see what they are diffing with your system
 
  • Thanks
Reactions: tks
Thanks fo reply
reptar said:
Your times are all over the place. With a diff of >1000sec it should be sending a panic to system logs and kill ntpd, which it looks like its doing.
Click to expand...
There are no messages in the system log and in /var/log/ntp.log
Code: 
# cat /var/log/messages | grep ntp | tail -8
Jun 30 20:51:37 bsd ntpd[83232]: ntpd 4.2.8p10-a (1): Starting
Jun 30 20:51:37 bsd ntpd[83233]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
Jun 30 20:51:37 bsd ntpd[83233]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Jun 30 20:51:37 bsd ntpd[83233]: switching logging to file /var/log/ntp.log
Jul  1 07:28:50 bsd ntpd[30449]: ntpd 4.2.8p10-a (1): Starting
Jul  1 07:28:50 bsd ntpd[30450]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
Jul  1 07:28:50 bsd ntpd[30450]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2017-12-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Jul  1 07:28:50 bsd ntpd[30450]: switching logging to file /var/log/ntp.log
reptar said:
kill the service and restart with the -g flag.
DO NOT use -x, itll take 150days to skew to the correct time if I'm mathing right.
Click to expand...
Now ntpd running with -g
Code: 
# ps -aux | grep ntpd
root     30450   0.0  0.2  20568  12476  -  Ss   09:15       0:01.39 /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift
root     74494   0.0  0.0  14828   2512  0  S+   19:01       0:00.00 grep ntpd
reptar said:
Did you manually set your ntp servers from your ntpq in your original post to /etc/ntp.conf?
poll them with sntp and see what they are diffing with your system
Click to expand...
I am using original /etc/ntp.conf
Code: 
# head -4 /etc/ntp.conf
#
# $FreeBSD: stable/11/etc/ntp.conf 314531 2017-03-02 01:23:17Z ian $
#
# Default NTP servers for the FreeBSD operating system.
 
What's your time showing now?
Per ntpd() -g will only produce a one time change, but can be done multiple times.

You can manually select servers/pools you want to use. Being your MSK timezones I'd select servers/servers close to you instead of letting the default pool auto select.

There is direction in the man page on how to set servers/pools and select a preferred server/pool to sync to.

Using sntp you can test which servers give you the best timing/offset/jitter. Utilities exist to test a big list of servers prioritizing all these parameters, and spit out the preferred list,but the name escapes me.

I'm not intelligent enough to tell from your first post if your machine is listening to machines on you local network as a sync-able source, and if that's the case if that takes priority above remote servers. There is an option in the man page to disable the listening to local machines and may be a direction to explore.

Here is a thing to read http://www.pool.ntp.org/en/use.html, has some hints to tell if you actually using time from the pool
 
  • Thanks
Reactions: tks
Good time. Problem solved.
ntpd_sync_on_start="YES"
 adds -g and solves the problem.
Thank you very much all for helping. Good luck.
 
You must log in or register to reply here.
Back
Top