Hi, I’m not sure what kind of issue I’m experiencing, but it’s somewhat weird and I couldn’t find any reliable info regarding it.
When I run date command multiple times, I can see that each second takes like 10 seconds in real world to advance, that makes the date/time drift constantly (days), regardless of NTP having proper settings in the dietpi-config.
What can be causing this?
Thanks!
hard to say why time is drifting. Do you have any constant high CPU usage?
Based on htop no, I don’t. Oddly, on htop the “refresh” seems to also be taking like 5-10 seconds.
anything on kernel error messages?
dmesg -l err,crit,alert,emerg
This is what I have:
[ 0.560847] bcm2708_fb soc:fb: Unable to determine number of FBs. Disabling driver.
[ 2.645181] sd 1:0:0:0: [sdb] No Caching mode page found
[ 2.645193] sd 1:0:0:0: [sdb] Assuming drive cache: write through
Which board is running dietpi? Is there RTC? What settings are configured in dietpi-config for time sync?
hmm it could be a CPU frequency issue as well. MichaIng Do you remember the case where we had to low CPU values leading to such issues?
What settings do you want me to look into?
Ok, so it looks like Joulinar answer was right. I had the minimum clock set to 100 mhz which apparently triggered this issue — set it back to 300 mhz and the seconds advance properly back again, although I don’t get the reason why.
The 100 mhz is the mininum iddle CPU frequency (which should be enough for time keeping) nevertheless, I also noticed that navigating the dietpi-config menus become faster by setting it back to 300 mhz, which is odd, because this is the iddle/minimum frequency, not max.
I guess we never talked about it but I assume you are using a Raspberry Pi?
Best to my knowledge this min 300 MHz needed CPU frequency is a limitation of RPi themselves. Means something which is not in our hand. Anyway we will review our config tool options to avoid someone setting it below 300 MHz on RPi.
Yes, this is a known issue: https://github.com/raspberrypi/firmware/issues/1431#issuecomment-853811959
miguelpruivo would you mind to open a new issue at the RPi repository: https://github.com/raspberrypi/firmware/issues
The one I linked above was actually about a different issue, has grown and has multiple issues mixed, so any post there won’t get much attention I guess.
The range and amount of stable frequency states is physically limited by the amount of PPL’s (Phase Locked Loops) for the CPU. On other RPi models any frequency below 600 MHz is not stable after 100 MHz frequency steps have been enabled with Linux 5.4, which is the reason the it cannot be lowered there at all. On RPi 4 there is probably a way to get 100 and 200 MHz stable as well, but until then, it should be limited to 300 MHz firmware wise, which is stable.
I also limited it in dietpi-config now to allow 300 MHz as minimum.