I’ve recently noticed that my DietPi clock is always running late.
Right after startup,
date accurately shows the current local time, but time gradually seems to slow down for the DietPi.
Now, about 13 hours later, it’s running 2 hours and 10 minutes late?
Does anybody know what’s happening here.
It’s as if time is passing more slowly for the DietPi.
We have seen such behaviour on RPI SBC where the CPU clock value was set below 300MHz. Usually minimum value should not be lower than 600MHz if I’m not mistaken.
You’re right. I had set the ARM Idle Frequency for my Raspberry Pi 4 to 300 MHz, and now that I’ve reverted back to 600 MHz, the clock works normally again.
Thanks for sharing your knowledge and again solving a problem of mine. It’s much appreciated!
I wanted to ask, the main website doesn’t seem to be working for me, is it down? https://dietpi.com/
Omg, I also had this issue, which caused other issues for sure. There should be a warning or did I not read it?
I guess we would need to adjust configuration options for RPi at least. We still do a statement, that 300MHz is a recommended value. But we know that it can cause issues (confirmed by RPI devs). Am I correct?
┌──────────────────────────────────────────────────┤ DietPi-Config ├───────────────────────────────────────────────────┐
│ ARM frequency (MHz) used by CPU governors powersave and schedutil/ondemand/conservative when on idle. │
│ - Current value: 600 │
│ - Recommended value: 300 │
│ - Minimum value: 300 │
│ - Default value: 600 │
│ - Setting a value below the minimum will reset to RPi defaults. │
│ 600_________________________________________________________________________________________________________________ │
│ <Ok> <Cancel> │
Actually we were only aware of clock below 300 MHz causing such issues, which is why we raised the minimum from 100 MHz to 300 MHz a while ago. I guess it depends on the exact hardware/SoC production then, every chip is different.
Where does RPi devs/foundation state that 300 MHz is causing issues already?
Probably I mixed it and understood it wrongly. In this case it was my mistake. Sorry for confusion
No need to, obviously we have a case here where even 300 MHz causes issues.
It makes sense to remove the “recommended” from the menu and show a note above the input box, so users know they need to raise it again when facing system clock issues.