xiaoxiang781216 commented 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, 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. > > I'm porting an application that is running reliably with RT Linux that have same configuration for a system clock and talking honestly I do not see any reason (strong argument) why it should not run the same with NuttX. > > Let's focus discussion on POSIX timers only and leave the `wdog` alone. We can have a separate discussion why we need to add one extra tick if `wd_start` is called from `wdog` expiration handler that is actually called from the timer ISR (exactly at the beginning of a phase). I agree with @patacongo that in general `wd_start` can be called at any time and we do not know are we at the beginning or in the middle or an the end of the phase, so `+1` 100% needed in general case, but if we are building a reoccurring event with `wdog` and `wd_start` is called from `wd_timer` (eventually from the system tick ISR) then adding one tick is a bit strange and IMO we just introduce the extra delay in the place where it is really not needed. -- 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]
