clock_get_uptime

[Gedare Bloom]

Hi,

I've written some code to try generating a synthetic load with a
(somewhat) predictable execution time. Based on a brief chat on IRC
with Joel, I decided to try using the clock_get_uptime routine.  I see
that uptime is updated during the rtems_clock_tick routine, which is
typically called in the clock ISR provided by each individual BSP.

I implemented a load generating loop as part of an RTEMS app, using
the CVS head and pc386 BSP in QEMU.  I observed some interesting
behavior when calling uptime in a tight loop.  In particular, I get
some backwards time-travel.

Here is a snippet of the code:
    rtems_clock_get_uptime(&start_ts);
    while(FOREVER) {
      rtems_clock_get_uptime(&stop_ts);
      _Timespec_Subtract(&start_ts,&stop_ts,&diff_ts);
      if (_Timespec_To_ticks(&diff_ts) >= Tick_Count[argument]) break;
    }

here, start_ts, stop_ts, and diff_ts are all struct timespec, and
Tick_Count[argument] is a parametrized integer value.  What is
happening is that the loop appears to be ending prematurely.

An example of the values of start_ts, stop_ts, and diff_ts are:
(gdb) p start_ts
$4 = {
  tv_sec = 0,
  tv_nsec = 200701252
}
(gdb) p stop_ts
$5 = {
  tv_sec = 0,
  tv_nsec = 200325952
}
(gdb) p diff_ts
$6 = {
  tv_sec = -1,
  tv_nsec = 999624700
}

I can see that stop_ts < start_ts, and that diff_ts reflects this
negative amount.  I'm trying to figure out why this is happening.  I
can trace stop_ts, and I am able to observe that it does in fact
increase, up to:
(gdb) p stop_ts
$27 = {
  tv_sec = 0,
  tv_nsec = 208797738
}
But then the next time I read stop_ts from clock_get_uptime, I get the
value 200325952.  Does anyone know why this might be happening?

Thanks,
Gedare