Re: [tlug] timing for geeks II.

[Ian Wells <ijw@example.com>]

On 12/19/05, Michal Hajek <hajek1@example.com> wrote:

Jim (jep200404@example.com) [051218 17:34]:
> What problem are you actually trying to solve (or understand)?

Exceptionally good question actually :)
I apologise, I should have cleared this one right from the beginning of
the thread....

I think this is the difference between problem and solution.  The problem you're trying to solve (and the one which we would like to hear about) is something *requiring* timing.  What are you trying to time?  Almost certainly (if it's hardware) you would be better off with a capture card rather than getting Linux to do something it's not really intended to do (e.g. something that, in hardware, records the time each signal change is received so that your software can get out of step with realtime a bit and still accomplish your task).  Or use a different OS for your timing, one which isn't pre-empting your process all the time.  Choosing Linux as the solution and then trying to solve its deficiencies may mean that that it's not necessarily adequate to solve your problem in the first place. 

Certainly it's not sufficient if you hope for 1us accuracy while using wall clock time and a pre-emptible process to compare the two, as you can't guarantee or even reasonably expect that your process will run for sufficient time in consecutive microseconds.

(I come from an automotive background, where monitoring crank position requires monitoring a changing-frequency signal up to 360kHz with e.g. a 16MHz processor, so there's quite a lot of hardware assist used, even with a hard realtime program.)

--
Ian.