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
