How do you measure the wait period? Are you togging a pin or used MCU free running HW timer?
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 > > > >
