Open HomeACcessoryKid opened 3 years ago
a friend also observed this kind of behaviour on an unrelated repository.
What they have in common is the use of CPU acceleration for specific activities. So for about 0.5 seconds at a time, the CPU goes to 160MHz and then back to 80MHz.
I switched to using extras/timekeeping which has a bit steeper learning curve, but performs perfect AFAIAConcerned If others bump into this, we might find a root cause in extras/sntp and solve it...
2Bcontinued
I used the example of extras/sntp and then, based on a timer that triggers every second, collect a time_t=time(NULL) when 60 triggers have passed
This should give a constant update of near 1 minute in reported time which is does... HOWEVER, after a certain time (not always the same), the clock reports backwards by 7:44:50 (not always the same, but within a minute yes). It then continues going backward for an amount of time (not always the same*) and at that 'moment in the past' is starts reporting again 1 minute up until it goes back by 7:44:xx again and then gets back in gear
*) for one session (uninterrupted by a restart) the bad-run-time was 115 minutes twice, but another session it is much more. Is this based on a bug? there seems to be some repeatable pattern so it suggests a code based issue.
Any help is appreciated,
relevant pieces of code below
and a few lines of the output
maybe a conflict in multiple places where time gets defined?