After a few moments the time is outdated

Creating a bug report/issue

Required Information

  • DietPi version | v8.17.2
  • Distro version | bullseye
  • Kernel version | 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
  • Architecture | arm64
  • SBC model | RPi 4 Model B (aarch64)
  • Power supply used | (EG: 5V 1A RAVpower)
  • SD card used | SSD

I have been running this OS for a few days. It has made my life much easier.
I run my smartHome as Docker here.
However, I have noticed that the time deviates massively. After only a few moments, the time is outdated again.
I do not know now if this is related, but I use as NTP Mirror. But even the Gateway option doesn’t work for me.

Here an extract from ‘journalctl -u systemd-timesyncd.service’:

-- Journal begins at Thu 2023-05-18 18:39:06 CEST, ends at Thu 2023-05-18 19:16:26 CEST. --
Mai 18 18:39:07 SmartHome systemd[1]: Starting Network Time Synchronization...
Mai 18 18:39:07 SmartHome systemd[1]: Started Network Time Synchronization.
Mai 18 18:41:11 SmartHome systemd-timesyncd[280]: Initial synchronization to time server (
Mai 18 18:41:11 SmartHome systemd[1]: Stopping Network Time Synchronization...
Mai 18 18:41:11 SmartHome systemd[1]: systemd-timesyncd.service: Succeeded.
Mai 18 18:41:11 SmartHome systemd[1]: Stopped Network Time Synchronization.

I hope this helps. Would be very happy about a feedback or solution.

we have seen such behaviour if CPU frequency was set to a too low value. Can you share

cat /boot/config.txt
1 Like
# Docs:
# Overlays:

# Max allocated framebuffers: Set to "0" in headless mode to reduce memory usage
# - Defaults to "2" on RPi4 and "1" on earlier RPi models

# If you get no picture, set the following to "1" to apply most compatible HDMI settings.

# Uncomment to adjust the HDMI signal strength if you have interferences, blanking, or no display.
# - Ranges from "0" to "11", use values above "7" only if required, e.g. with very long HDMI cable.
# - Default on first RPi1 A/B is "2", else "5", on RPi4 this setting is ignored.

# Uncomment if HDMI display is not detected and composite is being outputted.

# Uncomment to disable HDMI even if plugged, e.g. to force composite output.

# Uncomment to force a console size. By default it will be display's size minus overscan.

# Uncomment to enable SDTV/composite output on RPi4. This has no effect on previous RPi models.
# SDTV mode

# Uncomment to force a specific HDMI mode (this will force VGA).

# Uncomment to force an HDMI mode rather than DVI. This enables HDMI audio in DMT modes.

# Set "hdmi_blanking=1" to allow the display going into standby after 10 minutes without input.
# With default value "0", the display shows a blank screen instead, but will not go into standby.
# NB: Some legacy OpenMAX applications (OMXPlayer) cannot wake screens from real standby.

# Set to "1" if your display has a black border of unused pixels visible.

# Uncomment the following to adjust overscan.
# Use positive numbers if console goes off screen, and negative if there is too much border.

# Rotation

#-------RPi camera module-------

#-------GPU memory splits-------

#-------Boot splash screen------

#-------Onboard sound-----------



# NB: "enable_uart=1" will enforce "core_freq=250" on RPi models with onboard WiFi.

#-------SD card HPD-----
# Comment to enable SD card hot-plug detection, while booting via USB or network.
# NB: This causes constant CPU load and kernel errors when no SD card is inserted.




This should be the culprit, I have the same problems on my RPi 4, when the frequency is below 600MHz.

1 Like

Yes don’t set it below 600. Its know for RPI4 to not work correctly if min value has been set too low. I recommend to hash # the value and restart your system.

1 Like

I changed it in the dietpi-config menu. Now it is


Looks good so far. Thanks for your help.
Is it planned to fix this issue in the near future ?

This has nothing to do with DietPi. It’s related to RPi device and how CPU frequency is working there. Maybe @MichaIng could be more specific on this. If I’m not mistaken it is a known limitation of RPi4.

It is actually a known limitation on most other RPi models, which is why on those the minimum frequency cannot be lowered below 600 MHz anymore: [Kernel5.4] Lowering arm_freq_min leads to system hang/crash · Issue #1431 · raspberrypi/firmware · GitHub

On RPi 4 this mostly works, but we saw it by times that also the RPi 4 becomes unstable. Depends on the individual chip, it seems: Raspberry Pi | Slow system clock with arm_freq_min < 300 · Issue #4455 · MichaIng/DietPi · GitHub

1 Like

Could you please elaborate? DietPi-Performance > Overclocking ? DietPi-Performance > Overclocking > CPU Governor ? Default values in a RPi3B are default and schedutil respectively. ondemand and conservative CPU Governor settings seems to set a mininum of 600, whichever is more suited for your SBC. Thank you in advance.

I think he’s talkin about dietpi-config > 4 : Advanced Options > ARM Idle Frequency: [600 MHz]


And you did reboot after changing it?


Probably the issue is not the CPU frequency then. Could you test whether the same happens with performance governor?

I think there’s an misunderstanding. f
It works for me. Therefore, my post can actually be marked as “solved”. My answer was rather @derebo , who apparently also has the problem.