Incorrect time to first callback when using OS_TimerCreate API #271
Comments
jphickey
added a commit
that referenced
this issue
Oct 23, 2019
In VxWorks, the sigwait routine was not handling the actual time of the first interval, which basically meant that the start_time was elapsed twice before the first callback was generated. This exposed a few other small but significant details regarding how the intervals were dealt with across all operating systems. For VxWorks and RTEMS, where the timer interval is rounded up to an integer number of ticks, compute the actual interval time and write a debug message in case it is different than the intended value. This makes it more obvious to the user that some application/bsp changes might be necessary to get accurate timing. For all operating systems, the "reset" flag needs to be sampled AFTER the sigwait returns, not before it. This flag gets set when the OS_TimeBaseSet() API is called. Removes an unused POSIX delay routine that was intended to support use of clock_nanosleep() in place of the timer signal. This mode was never usable because OS_TimerCreate always allocates a signal and fails if it cannot do so. This code caused problems/incompatibilities for the sigwait model which IS used, so it needed to be removed.
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Oct 25, 2019
The timer code for VxWorks was fixed in bug nasa#271 and the coverage code test needs a corresponding update to cover the code change. This is kept as a separate update commit as neither changeset is merged to master yet.
skliper
pushed a commit
that referenced
this issue
Oct 31, 2019
In VxWorks, the sigwait routine was not handling the actual time of the first interval, which basically meant that the start_time was elapsed twice before the first callback was generated. This exposed a few other small but significant details regarding how the intervals were dealt with across all operating systems. For VxWorks and RTEMS, where the timer interval is rounded up to an integer number of ticks, compute the actual interval time and write a debug message in case it is different than the intended value. This makes it more obvious to the user that some application/bsp changes might be necessary to get accurate timing. For all operating systems, the "reset" flag needs to be sampled AFTER the sigwait returns, not before it. This flag gets set when the OS_TimeBaseSet() API is called. Removes an unused POSIX delay routine that was intended to support use of clock_nanosleep() in place of the timer signal. This mode was never usable because OS_TimerCreate always allocates a signal and fails if it cannot do so. This code caused problems/incompatibilities for the sigwait model which IS used, so it needed to be removed.
jphickey
added a commit
to jphickey/osal
that referenced
this issue
Dec 18, 2019
This is related to the change for nasa#271, where the return value of this function depends on the configured timer interval. The coverage test case for this was not updated in the original change.
skliper
pushed a commit
that referenced
this issue
Dec 30, 2019
This is related to the change for #271, where the return value of this function depends on the configured timer interval. The coverage test case for this was not updated in the original change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
There discrepancies between the expected first callback and the time the first callback actually occurs, for timers created via
OS_TimerCreate(). This is with regards to the "start_time" parameter.To Reproduce
The
timer-testexample program exposes this bug. It was never seen because on POSIX the difference is not substantial enough to cause failure, but on VxWorks it does fail.General sequence is:
Create a timer via
OS_TimerCreate()Set the timer using
OS_TimerSet()with start_time=2000000 (2 sec) and interval_time=400000 (400ms).The time between the OS_TimerSet call and the first timer callback should be 2 seconds (within system timer tick tolerances) but it is approximately 2.4 seconds on POSIX. On VxWorks the difference is even more substantial, causing failure of the timer-test example program.
Expected behavior
The time between the OS_TimerSet call and the first timer callback should be equivalent to the
start_timeparameter from the OS_TimerSet call.System observed on:
Ubuntu 18.04.2 LTS, 64 bit, using
posixOSAL buildVxWorks 6.9 on MCP750, using
vxworksOSAL buildBoth running the "timer-test" example program.
Additional context
This appears to be limited to cases where the backward-compatible OS_TimerCreate API is used. In this case an implicit timebase object is created just to service the single timer. In this mode, there is an initial condition issue in the wait routine, and the first interval therefore is not correct.
If the timer callback is registered via
OS_TimeBaseCreate()followed byOS_TimerAdd(), then it is OK.Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: