[TriLUG] High resolution timer calls and the kernel

[Sam Kalat]

Thanks for the link and info w/code.  It does look like I am getting a long 
wait for the user-space code, but that the call itself is giving a good time 
stamp.  I need to research this a bit more and also see what is different 
when running as root, and with that round-robin tactic supplied by Charles 
Fischer.

I don't know of a way to have the camera driver supply a signal to say when it 
is ready.  It was only through some testing that I was able to determine that 
they generate new buffers every so often after you crank them up, whether you 
are reading that information or not.  The actual frame rate is not 
necessarily the same as the one requested, too; there may be problems in the 
driver, but 10 fps is enough for me for now.

If I could generate an interrupt at a reliable time interval that would do, 
although this way has some advantages.  If I can control both breadth and 
depth attributes of the calculations, and I find that I've covered 40% of the 
breadth in 20% of my allotted time, I can increase the depth.  And so long as 
I can keep from asking for time stamps too frequently I think the delays in 
the calls will go back to normal.  

But even if I can't do that incremental feedback I can still keep track of how 
far I get each frame and use that to control what to do in future frames.  
This hasn't been an insurmountable barrier as much as a warning flag.  I 
don't want my inexperience with timing and scheduling to allow me to make 
avoidable mistakes with the program, hence my desire to understand what has 
already surprised me.

Thanks,
Sam



> Hi Sam,
>
> The "slowdown" you're seeing most likely is due to a combination of
> scheduling of your user-space process and "other things" (eg. I/O) that
> your processes is trying to do.  Remember, there are probably dozens of
> processes running on your system and they have to share CPU resources.
>
> See the email discussion thread at
>
>   http://archive.lug.boulder.co.us/bymonth/2003.02/msg00187.html
>
> for more discussion and some code.
>
> Also, the "are we there yet" way of dealing with time is mighty
> inefficient!  Have you thought about using some sort of interrupt
> mechanism so that you can cleanly "cut short" the results from the
> analysis of one frame _only_ when you get a signal that the next frame
> is ready?  That way, you won't have to explicitly check the time.
>
> Ed