Petro Karashchenko kirjoitti keskiviikko 17. toukokuuta 2023: > How do you measure the wait period? Are you togging a pin or used MCU free > running HW timer?
I used RISC-V MTIMER, so it is a free running HW counter at 1us resolution > > Best regards, > Petro > > On Wed, May 17, 2023, 5:43 PM Jukka Laitinen <jukka.laiti...@iki.fi> wrote: > > > > > On 17.5.2023 16.38, Gregory Nutt wrote: > > > On 5/17/2023 7:21 AM, Gregory Nutt wrote: > > >> On 5/17/2023 4:21 AM, Jukka Laitinen wrote: > > >>> > > >>> Hi, > > >>> > > >>> I just observed the behaviour mentioned in the subject; > > >>> > > >>> I tried just calling in a loop: > > >>> > > >>> " > > >>> > > >>> sem_t sem =SEM_INITIALIZER(0); > > >>> > > >>> int ret; > > >>> > > >>> ret = nxsem_tickwait_uninterruptible(&sem, 1); > > >>> > > >>> " > > >>> > > >>> , and never posting the sem from anywhere. The function return > > >>> -ETIMEDOUT properly on every call. > > >>> > > >>> But when measuring the time spent in the wait, I see randomly that > > >>> sometimes the sleep time was less than one systick. > > >>> > > >>> If I set systick to 10ms, I see typical (correct) sleep time between > > >>> 10000 - 20000us. But sometimes (very randomly) between 0 - 10000us. > > >>> Also in these error cases the return value is correct (-110, > > >>> -ETIMEDOUT). > > >>> > > >>> When sleeping for 2 ticks, I see randomly sleep times between > > >>> 10000-20000us, for 3 ticks 20000-30000us. So, randomly it is exactly > > >>> one systick too small. > > >>> > > >>> I looked through the implementation of the > > >>> "nxsem_tickwait_uninterruptible" itself, and didn't saw problem > > >>> there. (Actually, I think there is a bug if -EINTR occurs; in that > > >>> case it should always sleep at least one tick more - now it doesn't. > > >>> But it is not related to this, in my test there was no -EINTR). > > >>> > > >>> I believe the problem might be somewhere in sched/wdog/ , but so far > > >>> couldn't track down what causes it. > > >>> > > >>> Has anyone else seen the same issue? > > >>> > > >>> Br, > > >>> > > >>> Jukka > > >> > > >> > > >> If I understand what you are seeing properly, then it is normal and > > >> correct behavior for a arbitrary (asynchonous) timer. See > > >> https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays > > >> for an explanation. > > >> > > >> NuttX timers have always worked that way and has confused people that > > >> use the timers near the limits of their resolution. A solution is to > > >> use a very high resolution timer in tickless mode. > > >> > > >> > > > Oops. You are seeing a timer that is 1 tick too short. That is an > > > error and should never happen. Sorry for reading incorrectly. It was > > > still early in the morning here. > > > > > > The timer logic adds +1 tick to the requested to assure that that > > > error never occurs. If +1 were not added, the bad result would be > > > exactly as you describe (and as explained in the confluence reference). > > > > > > > > Hi, yes, exactly. Seeing timeout 1 tick too short. Sorry for not > > explaining it clearly enough :) > > > > I fear that there is now some bug. It was rather easy to re-produce, > > just a loop with few thousand iterations, and it occurs (infinite loop, > > 10 ms tick, less than a minute to catch). Most of the time it works ok; > > the sleep time is longer than the requested ticks. But when it triggers, > > the sleep is exactly one tick too short (and shorter than the requested > > timeout in ticks). > > > > I was just asking, if others have seen this as well; I'd like to know if > > it is really a bug in current nuttx main. It is always possible that > > there is something funny in our local build - although I can't see what > > it could be. > > > > -Jukka > > > > > > > > >
