Posting here just in case others need a solution for the same problem.
Problem was that my server time kept going off fast. I am on a VPS so some stuff was out of my control, but this is how I got it to work.
like I said NTP is running, but clock still goes off
# Don't forget to enable ntpd in /etc/rc.conf with:
# ntpd_enable="YES"
#
# The driftfile is by default /var/db/ntpd.drift, check
# /etc/defaults/rc.conf on how to change the location.
It may be a broken ACPI timer. The simplest solution then is to disable the ACPI timer in /boot/loader.conf:
debug.acpi.disabled="timer"
Or the BIOS may modify the TSC clock—perhaps to change the speed of the processor when running from batteries, or going into a power saving mode, but FreeBSD is unaware of these adjustments, and appears to gain or lose time. Then change to one of the other options on the server, see below.
ee /etc/ntp.conf
server 0.nl.pool.ntp.org iburst
server 1.nl.pool.ntp.org iburst
server 2.nl.pool.ntp.org iburst
server 3.nl.pool.ntp.org iburst
service ntpd restart
date
check:
ntpq -p
should show servers responding
To reset time:
service ntpd stop
run following command 3 or more times
ntpdate -u 0.nl.pool.ntp.org
service ntpd start
ntpq -p
Then check timecounter choice
sysctl kern.timecounter
find line:
kern.timecounter.choice: TSC(1000) i8254(0) ACPI-safe(850) HPET(950) dummy(-1000000)
find out which one is used with:
sysctl kern.timecounter.hardware
In my case options are: TSC i8254 ACPI-safe and HPET
TSC goes off fast.
Change timecounter with command:
sysctl kern.timecounter.hardware=i8254 or
sysctl kern.timecounter.hardware=ACPI-safe or
sysctl kern.timecounter.hardware=HPET or
sysctl kern.timecounter.hardware=TSC
Then check time again.
service ntpd stop
run following command 3 or more times
ntpdate -u 0.nl.pool.ntp.org
service ntpd start
check time with
date
check time against: http://time.is/
Once we find the right one, add the following line to /etc/sysctl.conf:
kern.timecounter.hardware=i8254
That's it folks, hope someone finds this useful, I know I will when I run into this again and lose this info from my local directory
Problem was that my server time kept going off fast. I am on a VPS so some stuff was out of my control, but this is how I got it to work.
like I said NTP is running, but clock still goes off
# Don't forget to enable ntpd in /etc/rc.conf with:
# ntpd_enable="YES"
#
# The driftfile is by default /var/db/ntpd.drift, check
# /etc/defaults/rc.conf on how to change the location.
It may be a broken ACPI timer. The simplest solution then is to disable the ACPI timer in /boot/loader.conf:
debug.acpi.disabled="timer"
Or the BIOS may modify the TSC clock—perhaps to change the speed of the processor when running from batteries, or going into a power saving mode, but FreeBSD is unaware of these adjustments, and appears to gain or lose time. Then change to one of the other options on the server, see below.
ee /etc/ntp.conf
server 0.nl.pool.ntp.org iburst
server 1.nl.pool.ntp.org iburst
server 2.nl.pool.ntp.org iburst
server 3.nl.pool.ntp.org iburst
service ntpd restart
date
check:
ntpq -p
should show servers responding
To reset time:
service ntpd stop
run following command 3 or more times
ntpdate -u 0.nl.pool.ntp.org
service ntpd start
ntpq -p
Then check timecounter choice
sysctl kern.timecounter
find line:
kern.timecounter.choice: TSC(1000) i8254(0) ACPI-safe(850) HPET(950) dummy(-1000000)
find out which one is used with:
sysctl kern.timecounter.hardware
In my case options are: TSC i8254 ACPI-safe and HPET
TSC goes off fast.
Change timecounter with command:
sysctl kern.timecounter.hardware=i8254 or
sysctl kern.timecounter.hardware=ACPI-safe or
sysctl kern.timecounter.hardware=HPET or
sysctl kern.timecounter.hardware=TSC
Then check time again.
service ntpd stop
run following command 3 or more times
ntpdate -u 0.nl.pool.ntp.org
service ntpd start
check time with
date
check time against: http://time.is/
Once we find the right one, add the following line to /etc/sysctl.conf:
kern.timecounter.hardware=i8254
That's it folks, hope someone finds this useful, I know I will when I run into this again and lose this info from my local directory
Last edited: