# Time Slow on MiniPC



## zolthar (May 28, 2020)

I am having issues with time on a pfSense platform, however it appears to be related to the FreeBSD platform itself.

Here is the pfSense thread: https://forum.netgate.com/topic/153890/time-always-slow-2-4-5/13

I have installed on another of the exact same unit without time issue and this custom MiniPC/NUC has the following specs:
* Intel Celeron N3350
* 4GB
* 64GB Storage
* Windows 10 Professional
* 4x Serial RS232
* 2x RJ45
* HDMI, Mini DP
* *Unknown Board manufacturer*

I have tried the following

Installed Ubuntu 20.04 Desktop
Installed PopOS 20.04
Installed Windows 10 1909
Checked BIOS time
Changed board battery
It appears to work correctly on other platforms and the seconds increment correctly.

However when I install pfSense or FreeBSD, the initial time is correct upon system boot then immediately becomes slow. Slow I mean for every 20 seconds in real life, the system moves about 3-4 seconds. This occurs regardless of the versions of the following and the NTP set:

Set NTP correctly within pfSense (ie. AU/Melbourne +10 GMT 0.au.pool.ntp.org)
Installed pfSense 2.4.4
Installed pfSense 2.4.5
Installed FreeBSD 12.1
I am trying to find the latest BIOS and will update this thread if I can source.


----------



## SirDice (May 28, 2020)

You can try changing the kern.eventtimer.timer sysctl(8). Another thing to check are the C states, `sysctl dev.cpu | grep cx_usage` and `sysctl -a | grep cx_lowest`. And last but not least, kern.hz is something to play with (try setting it to 100).

Not the same issue but it seems to have a similar effect: PR 192315


----------



## zolthar (May 28, 2020)

[2.4.5-RELEASE][admin@pfSense.localdomain]/root: sysctl dev.cpu | grep cx_usage
dev.cpu.1.cx_usage_counters: 17225 0 0
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 16349us
dev.cpu.0.cx_usage_counters: 25013 0 0
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 21386us

[2.4.5-RELEASE][admin@pfSense.localdomain]/root: sysctl -a | grep cx_lowest
hw.acpi.cpu.cx_lowest: C1
dev.cpu.1.cx_lowest: C1
dev.cpu.0.cx_lowest: C1

[2.4.5-RELEASE][admin@pfSense.localdomain]/root: vi /boot/loader.conf
kern.cam.boot_delay=10000
kern.ipc.nmbclusters="1000000"
kern.ipc.nmbjumbop="524288"
kern.ipc.nmbjumbo9="524288"
autoboot_delay="3"
hw.usb.no_pf="1"
net.pf.request_maxcount="400000"
kern.hz=100

Rebooted after applying the kern.hz and didnt make any difference so far.

Sorry I am probably just above begginer in my knowledge with FreeBSD, let alone Lunix - can you please elaborate on how I can apply this:
"You can try changing the kern.eventtimer.timer sysctl(8)"

EDIT: According to comment https://forum.netgate.com/topic/153890/time-always-slow-2-4-5/23 and https://forum.netgate.com/topic/153890/time-always-slow-2-4-5/24, this could be a faulty RTC hardware. Willing to try other solutions as I may not get the RMA.


----------



## SirDice (May 28, 2020)

zolthar said:


> can you please elaborate on how I can apply this:
> "You can try changing the kern.eventtimer.timer sysctl(8)"


PCs have different timers these days. The most common is hpet(4). Apparently that hpet(4) isn't implemented correctly, or dodgy, or something else. As this is a custom mini PC there may be something that FreeBSD doesn't like about it. Switching to a different event timer could circumvent this. 


```
% grep timer /var/log/messages*
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "LAPIC" quality 600
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "HPET" frequency 14318180 Hz quality 550
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "HPET1" frequency 14318180 Hz quality 440
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "HPET2" frequency 14318180 Hz quality 440
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "HPET3" frequency 14318180 Hz quality 440
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "HPET4" frequency 14318180 Hz quality 440
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "HPET5" frequency 14318180 Hz quality 440
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "HPET6" frequency 14318180 Hz quality 440
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "RTC" frequency 32768 Hz quality 0
/var/log/messages.2:May 10 17:31:37 maelcum kernel: attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
/var/log/messages.2:May 10 17:31:37 maelcum kernel: Event timer "i8254" frequency 1193182 Hz quality 100
/var/log/messages.2:May 10 17:31:37 maelcum kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
```


----------



## zolthar (May 29, 2020)

SirDice thank you for your replies. However my awesome Account Manager pushed the RMA through and with the replacement hardware all timing is perfect. Thank you again and appreciate your comments.


----------

