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 debian.pool.ntp.org 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 116.202.14.29:123 (2.debian.pool.ntp.org).
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: https://www.raspberrypi.com/documentation/computers/config_txt.html
# Overlays: https://github.com/raspberrypi/firmware/blob/b150147d0135e5ba4bed7e30cda8ff96ce7d92f8/boot/overlays/README

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

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

# 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.
#config_hdmi_boost=5

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

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

# Uncomment to force a console size. By default it will be display's size minus overscan.
#framebuffer_width=1280
#framebuffer_height=720

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

# Uncomment to force a specific HDMI mode (this will force VGA).
#hdmi_group=1
#hdmi_mode=1

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

# 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.
hdmi_blanking=1

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

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

# Rotation
#display_hdmi_rotate=0
#lcd_rotate=0

#-------RPi camera module-------
#start_x=1
#disable_camera_led=1

#-------GPU memory splits-------
gpu_mem_256=16
gpu_mem_512=16
gpu_mem_1024=16

#-------Boot splash screen------
disable_splash=1

#-------Onboard sound-----------
dtparam=audio=off

#-------I2C-------------
#dtparam=i2c_arm=off
#dtparam=i2c_arm_baudrate=100000

#-------SPI-------------
#dtparam=spi=off

#-------Serial/UART-----
# NB: "enable_uart=1" will enforce "core_freq=250" on RPi models with onboard WiFi.
enable_uart=0

#-------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.
dtparam=sd_poll_once

#-------Overclock-------
temp_limit=65
initial_turbo=20

over_voltage=4
arm_freq=1900
core_freq=600

#over_voltage_min=0
arm_freq_min=300
#core_freq_min=250
#sdram_freq_min=400
arm_64bit=1
dtoverlay=disable-wifi

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

arm_freq_min=600

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]

Exactly.
image

And you did reboot after changing it?

yes

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.

2 Likes