[rtl] 32 rt-clock-ticks binned? (fwd)

[bionic@vassalboro.bu.edu]

(Glad to see we're back on line...)

Hello, I recently switched up to linux2.2.13 & NM rtl-2.0.

Prior to the upgrade, I had linux2.2.10 & NM rtl-Beta11 running
a neuron control algorithm, written entirely in 32-bit integer math,
running at 10kHz.

With the upgrade, I switched to floating point math, and found input/
output latencies extending beyond 100us -- which doesn't mesh well
with 10kHz operation :-(.  Upon switching back to integer math, I find
that my latency/jitter combo occasionally still extends beyond 100us, even
when I remove everything computationally expensive from the periodic
algorithm. (The only thing I'm doing is reading a single channel of a daq
board - maybe I should check comedi driver???)

Looking further into the problem, I examine the # of clock ticks I have
left after each cycle period - it's always a multiple of 32 (from
rt_get_time). Prior to switching versions, I remember getting single tick
precision.

Thought I'd see if any of you had some quick advice, thanks--

Chuck

****
Sent by the Comedi mailing list - <comedi@stm.lbl.gov>  To unsubscribe,
send mail to <comedi-request@stm.lbl.gov> with "unsubscribe" in the body.

--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/