patacongo commented on pull request #5421:
URL: https://github.com/apache/incubator-nuttx/pull/5421#issuecomment-1030698632
When I said that the tests that most people run are "faulty", the usual
problem is that they are starting the watching timer in phase with the system
time, essentially at phase 0. That is not a random start time, but is a fixed
worst case start time and results in the largest error each time. That is a
consequence of the faulty test. If the wdog is started at random times, you
would see that the behavior is more or less perfect.
The way to avoid accumulating errors from wdog times (which have inherent
time errors anyway) is to use the current time to determine that time of the
next tick.
For example, don't do the moral equivalent of:
```
for (; ;)
{
delay(x);
}
```
That might causes a loop with a period of x+1 on a system that not busy. It
would then run synchronous with the system time in that case ("faulty"). On a
busy system, the period could be nearly random, which is maybe worse.
But if you do something logically equivalent to:
```
clock_t last_time = current_time;
for (; ; )
{
clock_t next_time = last_time + x;
clock_t current_time = clock_systime_ticks();
int ticks = next_time - current_time;
last_time = next_time;
delay(ticks);
}
```
That is crappy code (any maybe not even correct), but you get this idea.
You track the time that you want using the current time error for corrections.
This may result in with a potentially variable number of ticks. And the time
will never drift.
If the delay is one tick to large, it will be one tick smaller next time.
This should stabilize quickly to a good periodic timer and is better resistant
to system load.
You can even do some dithering to get effectively higher resolution. For
example, I could generate a period event that is 2.5 x the system timer
(although each period could differ by one tick).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
