Time drift/system clock too fast on a PFSense VM
My pfSense VM's clock is running too fast for NTP to handle +11.5% or about +7 seconds every minute.
I can fix this temporarily, by switching my kern.timecounter.hardware to ACPI-Fast:
but this does not persist after a reboot.
So, how can I make this setting stick between reboots and upgrades?
What I have tried that has not worked:
Adding the following to /etc/sysctl.conf
Adding the following to /boot/loader.conf.local
What I am trying next in my /boot/loader.conf.local
Output that may help:
kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) i8254(0) dummy(-1000000)
I have looked at a similar post form 2012, but they did not find a way to resolve this:
What hardware is your host, what hypervisor?
I have been running pfsense on esxi for long time, and have never seen any issues with the clock drifting.. Mine is set to HPET..
[2.3.2-RELEASE][firstname.lastname@example.org]/: sysctl kern.timecounter
kern.timecounter.choice: TSC(-100) ACPI-fast(900) i8254(0) HPET(950) dummy(-1000000)
[2.3.2-RELEASE][email@example.com]/: sysctl kern.hz
VMware ESXi, but it's in a hosted so not much I can change on the back-end.
The issue is that I am not able to set sysctl values on the PFsense box… I can change them using a similar method for other BSD systems, but not this one.. so not sure what I need to change for the change to be persistent and survive upgrades.
I can set the variable once it is running, but not at boot :-(
KOM last edited by
I also run under ESXi and my timecounter.hardware is also HPET like John's. I wonder who/why it get set differently on your end.
No clue, it should detect the best timer, but it is not.
In this case it's best to set the quality manually, but not sure how to do this with pfSense…
w0w last edited by
Try add the following to /boot/loader.conf.local
If it does not work then you can use an own shell script.
#!/bin/sh sysctl kern.timecounter.hardware="ACPI-fast"
Just put it into /usr/local/etc/rc.d change rights to 0755 and reboot
Damn, I tried the first one already.
On my FreedBSD 10.3 system editing the /etc/sysctl.conf worked to change the timecounter.
Not sure what needs to be set to make this change permanent…
I added the script in /usr/local/etc/rc.d/fixtime, as w0w suggested, the permissions are set correctly and I can execute the script by running it, which works, but it did not get launched on reboot.
so.. I'm still stuck.
There must be something special pfsense is doing that freeBSD is not doing. I do see other threads in FreeBSD about this issue, and they are resolved with editing the /etc/sysctl.conf kern.timecounter.hardware... it's even in the manual
Is there a pfSense manual for sysctl changes to the timecounter?
doktornotor Banned last edited by
No idea what are you doing with /boot/loader.conf.local, works just fine here. Use the Shellcmd package if it doesn't work for you.
[solved] I got it, it is done in the GUI:
System -> Advanced
So, basically most stuff that you would put in /etc/sysctl.conf or /boot/loader.conf.local goes in the GUI…
Here is a link related to the issue:
Enabling Speedstep: To get it up and running you need to do a few things:
Set the timecounter to use the i8254 device with
To make this setting permanent add it to the system tunables table in the webgui:System: Advanced: System Tunables:
Enable powerd in the webgui in System: Advanced: Miscellaneous:
To force it to use EST rather than throttling or p4tcc add the following lines to loader.conf.local
I've tried in in two separate esxi 6 environments, built a fresh pfsense VM in each, and neither one lets you change this setting via /boot/loader.conf.local. Are you saying that they change to the file then rebooting worked for you to force a specific timecounter, or are you saying that the time did not drift?
pfsense versions 2.3.2 and 2.3.2_p1
w0w last edited by
I think the script should be not just /usr/local/etc/rc.d/fixtime but
I have two scripts that are working fine on startup.
May be its needed full path to sysctl to be added.
Anyway I glad you have solved it, but it looks a little bit strange that nothing works as it should just for you. I think the devil is in the details.