NTP daemon error clock unsyncronized

[Schoerch]

Hello,

I am trying to get the ntpd to work on my hardware. Unfortunately the opensense can not work together with the local timers. The system is an IPC with Intel(R) Celeron(R) J4125 CPU @ 2.00GHz (4 cores, 4 threads), 8GB RAM, 128 GB M2 SDD.

The ntpd process itself is running but it does not respond to the client requests from the lan. In the ntp log i see the following entries.

Code: [Select]

0.0.0.0 c016 06 restart
0.0.0.0 c012 02 freq_set kernel 0.000 PPM
kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
0.0.0.0 c01d 0d kern kernel time sync enabled
kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

While researching, I found various forum posts about it and tried everything (as well as how I understood it). Unfortunately, the entries are a bit older and do not refer to the current FreeBSD in use...

I have tested several settings of the syctl timer parameters but have not found one that works.

Code: [Select]

# sysctl kern.timecounter.choice
kern.timecounter.choice: TSC(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000)

# sysctl kern.eventtimer.choice
kern.eventtimer.choice: LAPIC(600) HPET(550) HPET1(440) HPET2(440) HPET3(440) HPET4(440) i8254(100) RTC(0)

I always get at ntpdate status 0x41 (PLL,UNSYNC)

Code: [Select]

# ntptime
ntp_gettime() returns code 5 (ERROR)
time e76d6136.0cafe000  Sat, Jan 14 2023 18:13:26.049, (.198049559),
maximum error 16369000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
modes 0x0 (),
offset 0.000 us, frequency 0.000 ppm, interval 4 s,
maximum error 16369000 us, estimated error 16000000 us,
status 0x41 (PLL,UNSYNC),
time constant 3, precision 0.000 us, tolerance 496 ppm,
pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us,
intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
[code]

Is this a general problem with the Intel J4125 CPU?
Is it possible that a kernel bug has been replaced?


[meyergru]

On my J4125 system, NTPD works fine, so it cannot be the CPU.

Did you read this thread: https://forum.opnsense.org/index.php?topic=18557.0 ?

One problem could be that the system time is off by a too large margin in the first place, such that the clock source is not being accepted. You could stop the NTPD daemon, start ntpdate once and then try again.

Another possbile problem could be that the clock drifts too much, e.g. on a VM. Which clock source is auto-selected, BTW? You did not show the output of "sysctl kern.timecounter".

[Schoerch]

Sorry for my long response,

yes i read this post including all linked and other related posts. I know the basic problems with time drifts and virtualisation since 15 years (Vmware, XEN, KVM).  I have real hardware here.

My actual settings:

Code: [Select]

kern.eventtimer.timer -> HPET
kern.timecounter.hardware -> ACPI-fast

None of avail timers and timeconters variants get by ntpdate "status 0x2001 (PLL,NANO)" is is allways "status 0x41 (PLL,UNSYNC)". the BIOS date and time is right. My old working time provider (Sophos UTM on HP Z420) has the same time and the same ntp pools .

Today i upgrade to 23.1_6 and the problem still present

PS: At work I have several virtual OPNsense without any ntp problems.

[meyergru]

On my J4125 system, I see:

Code: [Select]

kern.eventtimer.timer: LAPIC
kern.timecounter.hardware: TSC
kern.timecounter.choice: TSC(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000)
kern.eventtimer.choice: LAPIC(600) HPET(550) HPET1(440) HPET2(440) HPET3(440) HPET4(440) i8254(100) RTC(0)

I do not recall to have done anything to have influenced the choice, but it works:

Code: [Select]

# ntptime
ntp_gettime() returns code 0 (OK)
  time e78a1b2f.e346ed24  Sun, Feb  5 2023 13:10:23.887, (.887801957),
  maximum error 126218 us, estimated error 277 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -455.530 us, frequency 6.921 ppm, interval 4 s,
  maximum error 126218 us, estimated error 277 us,
  status 0x2001 (PLL,NANO),
  time constant 9, precision 0.001 us, tolerance 496 ppm,
  pps frequency 6.975 ppm, stability 0.000 ppm, jitter 0.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.