clock_gettime and absolute timers

I am seeing a rather bizarre problem in some data that I acquire with an
ARVOO framegrabber. The camera runs at 100 Hz so I get a frame every 10
msec. The ARVOO has a callback as each frame is acquired and I use the
callback to copy the video data to a shared memory region and also to tag
each frame with a sequence number and a timestamp. The normal operation
for our system is to have an absolute timer trigger the acquisition of
frames at 15 minute intervals. In some of the data that has been acquired
by this method I am seeing unrealistic values for the timestamps (obtained
by clock_gettime() in the callback). The first 3 or 4 frames will have
timestamp values at a much later time than the succeeding frames. I did a
calculation and came up with a value of 900 seconds LATER than the frames
that follow. The fact that 900 seconds is 15 minutes leads me to suspect
that there is some crosstalk between reading the system clock and the use
of timers (at least absolute timers). The sequence numbers and the video
content indicate that these first few frames are valid and in the proper
temporal sequence.

I am running 6.3.0.

Thanks,
Doug Owens

Or more likely you’re not properly mutexing your accesses to shared memory,
and the first 3 or 4 frames with the bogus timestamp were put there after
you entered the aquisition operation but before you got the data.

Marty Doane
Siemens L&A

“Doug Owens” <owens2@llnl.gov> wrote in message
news:crhehb$k9h$1@inn.qnx.com

I am seeing a rather bizarre problem in some data that I acquire with an
ARVOO framegrabber. The camera runs at 100 Hz so I get a frame every 10
msec. The ARVOO has a callback as each frame is acquired and I use the
callback to copy the video data to a shared memory region and also to tag
each frame with a sequence number and a timestamp. The normal operation
for our system is to have an absolute timer trigger the acquisition of
frames at 15 minute intervals. In some of the data that has been acquired
by this method I am seeing unrealistic values for the timestamps (obtained
by clock_gettime() in the callback). The first 3 or 4 frames will have
timestamp values at a much later time than the succeeding frames. I did a
calculation and came up with a value of 900 seconds LATER than the frames
that follow. The fact that 900 seconds is 15 minutes leads me to suspect
that there is some crosstalk between reading the system clock and the use
of timers (at least absolute timers). The sequence numbers and the video
content indicate that these first few frames are valid and in the proper
temporal sequence.

I am running 6.3.0.

Thanks,
Doug Owens

The acquisition thread is the only thing accessing the shared memory at
the time of the acquire. I wait until the desired number of frames (in
this case 256) have been acquired before attempting to read the data.
Even with the relatively slow IDE drive this is done in a matter of
seconds - leaving me with a saved file showing that the frames came from
15 minutes in the future. Also, this problem has not mainfested when I
use sleep() to simulate the timer functions.

I improved things to some extent by replacing my calls to clock_gettime
with ClockCycles. I ran overnight (15 min. intervals) and saw no problems
until this morning when the same 900 second jump showed up in the
ClockCycles data. This is more confusing because the docs claim that all
ClockCycles does is read the (in this case Pentium’s ) time stamp
register. If this is true then I really have invented the time machine.

Doug


Marty Doane wrote:

Or more likely you’re not properly mutexing your accesses to shared memory,
and the first 3 or 4 frames with the bogus timestamp were put there after
you entered the aquisition operation but before you got the data.

Marty Doane
Siemens L&A

“Doug Owens” <> owens2@llnl.gov> > wrote in message
news:crhehb$k9h$> 1@inn.qnx.com> …
I am seeing a rather bizarre problem in some data that I acquire with an
ARVOO framegrabber. The camera runs at 100 Hz so I get a frame every 10
msec. The ARVOO has a callback as each frame is acquired and I use the
callback to copy the video data to a shared memory region and also to tag
each frame with a sequence number and a timestamp. The normal operation
for our system is to have an absolute timer trigger the acquisition of
frames at 15 minute intervals. In some of the data that has been acquired
by this method I am seeing unrealistic values for the timestamps (obtained
by clock_gettime() in the callback). The first 3 or 4 frames will have
timestamp values at a much later time
than the succeeding frames. I did a
calculation and came up with a value of 900 seconds LATER than the frames
that follow. The fact that 900 seconds is 15 minutes leads me to suspect
that there is some crosstalk between reading the system clock and the use
of timers (at least absolute timers). The sequence numbers and the video
content indicate that these first few frames are valid and in the proper
temporal sequence.

I am running 6.3.0.

Thanks,
Doug Owens