If you need it, install DBus:
apt install dbus
systemctl start dbus
timedatectl
With RPi 3 in particular, also from other RPi models but less often/critical, we know that reducing the min/idle CPU frequency too much causes the clock to run too slow. We already raised the possible minimum that can be set in dietpi-config to 300 MHz, but there are individual boards which have issues with that as well, and rare cases even show this behavior with default idle clock. There are some good and some bad chips, sadly.
You can address this with hourly time sync mode, or daemon mode, depending on how precise it needs to be. Or of course raise the minimum frequency … oh, I just recognized we removed the option completely for anything below RPi 4, for this reason … and I remember there were even more critical issues in a few cases: RPi hangs and crashes with lowered idle/min clock on Linux 5.4.51+ · Issue #3690 · MichaIng/DietPi · GitHub
… if I remember correctly it is even ignored by the RPi firmware on these models.
I just enabled the CPU scheduler based min/max frequency limits option for those models for next DietPi release, so the minimum frequency can be raised to test whether it helps: dietpi-config: show scaling frequency limits option on RPi 0-3 · MichaIng/DietPi@b3bce56 · GitHub
To test:
for i in /sys/devices/system/cpu/cpufreq/policy[0-9]*
do echo 900000 > "$i/scaling_min_freq"
done
Applies 900 MHz min/idle frequency. See whether it changes something. Of course might not be a great solution due to higher power consumption => heat emission.
To check which frequencies are available:
for i in /sys/devices/system/cpu/cpufreq/policy[0-9]*
do cat "$i/scaling_available_frequencies"; echo
done
AFAIK there is more possible between 600 and 900. Maybe 700 and maybe this solves the issue already.