Fix #271: Correct interval time computations #277
Conversation
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.
There was a problem hiding this comment.
I like the posix implementation, it's easier to follow. Any need in posix/linux to check for a timer interval that is different due to the tick rate (like RTEMS and vxWorks?)
I like the OS_DEBUG warnings that tell the user that the interval may be different.
In vxWorks was the posix timer API used so it could be similar to the posix code? Does the vxWorks API offer any features that the posix does not?
On all my testing on various Linux/Glibc implementations, the timers have always worked correctly. That is, for any interval you specify, the implementation generates a signal at that interval, regardless of the system timer tick period. I haven't dug through the Glibc implementation, but it seems they are implementing whatever special sauce is needed to obtain the specific interval that was requested. I guess that's one of the benefits of using a full-fat C library instead of a trimmed-down one.
Does VxWorks offer a better timer API than the posix(-ish) API that is being used here? This timer setup code was lifted from the vxworks6 OSAL and the same API was used there. Honestly, I was surprised to see such a blatant difference between the requested interval and the actual provided interval, particularly because the requested interval was an exact multiple of timer ticks, yet timer_settime still added an extra tick to it, so it was basically just wrong at that point. It strikes me as a bug in the implementation. Reading back the interval with timer_gettime is basically just a workaround for this bug, but should work fine on platforms that work correctly too. |
|
CCB 20191030 - Code reviewed and approved |
skliper
added
the
CCB:Approved
Describe the contribution
Fixes issue #271, corrects the time intervals returned by the sigwait() routines for all three operating systems (POSIX, RTEMS, VxWorks).
Testing performed
Testing is focused on the operation of the
timer-testexample program and variations thereof.Verified that all callbacks from all timers correlate with the configured "start_time" and "interval_time" parameters passed to the OS_TimerSet() configuration.
Verified CFE still boots and runs OK. (stops FLYWHEEL as normal based on 1Hz tick)
Expected behavior changes
No changes to applications/CFE.
The
timer-testexample program now runs and passes consistently on all platforms.System(s) tested on:
Ubuntu 18.04.2 LTS 64 bit (simulation)
RTEMS 4.11 pc686 BSP running in QEMU
MPC750 VxWorks 6.9
Contributor Info
Joseph Hickey, Vantage Systems, Inc.