xiaoxiang781216 edited a comment on pull request #5424: URL: https://github.com/apache/incubator-nuttx/pull/5424#issuecomment-1030873038
> @xiaoxiang781216 I'm familiar with FreeRTOS delay interface and delays are not a part of this PR. I think that periodic POSIX timer use case that I'm trying to fix is more similar to https://freertos.org/RTOS-software-timer.html than to https://www.freertos.org/vtaskdelayuntil.html But in a proposed example > > ``` > clock_t last_time = current_time; > for (; ; ) > { > clock_t next_time = last_time + x; > clock_t current_time = clock_systime_ticks(); > int error= next_time - current_time; > last_time = next_time; > delay(x + error); Here should be `error` not `x + error`. > } > ``` > > if the task is preempted (for example for 1-2 system ticks) right before a `delay` call, then app periodic logic and compensation calculation will be screwed-up. I've been working for a years with mission critical systems and learned that lesson well. No, in this case you will delay with few ticks(even skip the sleep in case of error <= 0) and then catch up the sched jitter. So you get one tick error at most in each callback for a long run(assume you don't get error < 0). > > The only reliable way is to have a timer that posts a periodic event and task that is waiting for that event. Now the question is should it be a MCU HW timer or OS SW timer based on internal OS clock. It is no difference(of course, I assume that both implementation is right and accuracy) since the internal OS clock is also built on top of one HW timer. > @xiaoxiang781216 @patacongo please undesrtand me write, the question is not about can I or can not I code a periodic processing in a write way, but about how timers are operating. I could easily implement `board_timerhook()` and post an event to my task each third system tick and get the reliable operation. What I'm trying to say is that if there is not blockers for periodic POSIX timer to expire in time then it should expire in time (for example if I have 10ms system tick and configure POSIX timer to have periodic expiration with 30ms period then timer should expire each 30ms and not each 40ms. I'm not configuring 35ms or 37ms, but 3 multiples of system tick). If you config your system with 10ms tick and set a 30ms expiration, you will get it fire between 30ms-40ms(any values between them is possible). Even with your patch(#5421), you will get it fire between 20ms-30ms, no difference from the accuracy view. If you set a 30ms period POSIX timer, and always get the callback at 30+10, 60+10, 90+10... 30*n+10, it's a good implementation. > If you trying to convince me that we should have crappy timers, then I'm very disappointed. > If you want to achieve the more accuracy, the only choice is to reduce the tick length. For example, if you set tick to 1ms, you get the sequence as 30+1, 60+1, 90+1...30*n+1. > How the POSIX timers are implemented, that is another question. Currently they are relying on `wdog` that has it's implemented is a way as it is designed If POSIX timer can achieve that each callback happen between [n*period, n*period+tick), you can't do better since wdog can only achieve this accuracy. >, but if we need to change that to get reliable and well expected operation then I'm fine with that. I feel that we mixed in a discussion timers and `wdog`, so there are multiple threads in this discussion that I want to separate. If the accuracy of wdog doesn't match your expectation, we have to redesign the wdog(the interface may even change to not use the tick as unit). It's impossible to fix the problem by add or sub 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]
