clock_gettime() result going backwards on LEON3?

[Joel Sherrill]

On 6/23/2015 9:11 AM, Miller, Scott A. wrote:
> Hello,
>
> I'm observing that intermittently, that two successive calls to clock_gettime() will result in the 2nd timespec result being "before" the 1st timespec result.
>
> Here's the code and some example output showing this:
>
> <code snippet>
>
> #include <rtems.h>
> #include <bsp.h>
> #define CONFIGURE_INIT
>
> rtems_task Init(rtems_task_argument ignored);
>
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER      1
> #define CONFIGURE_INIT_TASK_ATTRIBUTES               RTEMS_FLOATING_POINT
> #define CONFIGURE_INIT_TASK_STACK_SIZE               (10 * RTEMS_MINIMUM_STACK_SIZE)
> #define CONFIGURE_MAXIMUM_TASKS                      13
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> #define CONFIGURE_MAXIMUM_DRIVERS                    16
> #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS     32
> #define CONFIGURE_EXTRA_TASK_STACKS                  (10 * RTEMS_MINIMUM_STACK_SIZE)
> #define CONFIGURE_MAXIMUM_POSIX_MUTEXES              rtems_resource_unlimited(10)
> #define CONFIGURE_MAXIMUM_POSIX_CONDITION_VARIABLES  rtems_resource_unlimited(10)
> #define CONFIGURE_MAXIMUM_POSIX_SEMAPHORES           rtems_resource_unlimited(10)
> #define CONFIGURE_UNIFIED_WORK_AREAS
> #include <rtems/confdefs.h>
>
> ....
>
>      struct timespec time1;
>      struct timespec time2;
>      uint32_t i = 0;
>
>      while (TRUE) {
>          clock_gettime(CLOCK_REALTIME, &time1);
>          clock_gettime(CLOCK_REALTIME, &time2);
>
>          if (time1.tv_sec == time2.tv_sec) {
>              if (time2.tv_nsec < time1.tv_nsec) {
>                  PRINTF("Violation!\n");
>                  PRINTF("%09u - %09u\n", time1.tv_sec, time1.tv_nsec);
>                  PRINTF("%09u - %09u\n", time2.tv_sec, time2.tv_nsec);
>              }
>          }
>
>          i++;
>
>          if (0 == (i % 1000)) {
>              PRINTF("Completed %d iterations...\n", i);
>          }
>      }
>
> </code snippet>
>
> <output>
>
> (gdb) run
> Completed 1000 iterations...
> Completed 2000 iterations...
> Completed 3000 iterations...
> Violation!
> 000000000 - 169994000
> 000000000 - 160002000
> Completed 4000 iterations...
> Completed 5000 iterations...
> Completed 6000 iterations...
> Violation!
> 000000000 - 409994000
> 000000000 - 400002000
> Completed 7000 iterations...
> Completed 8000 iterations...
> Completed 9000 iterations...
> Completed 10000 iterations...
> Completed 11000 iterations...
> Violation!
> 000000000 - 769993000
> 000000000 - 760001000
>
> </output>
>
> I'm running RTEMS 4.10.99 against the LEON3 (GR712RC) BSP.
>
> Is this expected behavior, or am I doing something incorrectly?

No it is not expected.

What date did you pull the code? Is it up to date?

> Thanks.
>
> Scott
>
> --
>
> Scott Miller | 210-522-4249 | Senior Research Engineer | Southwest Research Institute
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985