Callback latency problems. was: rtlinux dma ...

Hi,

# Would you clarify what you mean by the latencies being too big with
# dma enabled?

It's like this (considering data before the glitch happens). The
requested period here is 200us and the times are measured in ns
between consecutive executions of the callback with the RTAI
function rt_get_cpu_time_ns():

Without DMA (after about 25 million loops):

Average: 199.98 us
Worst cases: 177 us and 221 us
not a single one with an error larger than 25%)

With DMA (usually just a few million loops):

Average: 199.98 us
Worst cases: 23 us and 382 us
99.90% of the times were shorter than 150us or longer than 250us

I've not checked the timestamps, just the differences. I'd guess they are
switching between a short and a long one, since the average is the same.

If it is important to know the exact timing (how the delays vary sample
by sample), please tell me, so I could modify the program to save the
information.

# That sounds pretty suspicious. Does your computer have a bios setting
# to put the machine into low-power mode after an hour idle?

Sorry, I think I used the wrong term. By "idle" I meant: running just
the test program without the "torture" tests. Even this way we still
have a RT part running at 5KHz, sending data to a FIFO at 500Hz, and a
user level application printing data to a standard terminal (no frame
buffers) at 50Hz with ncurses.

Yes, this computer had problems with power management. But since I
disabled everything related at the BIOS and also the SMIs "by hand" the
problems went away with RTAI. It's strange that the glitch does not
happen using RTAI periodic tasks and reading just a few channels with
comedi_data_read() instead of using callbacks. Unfortunately this is not
a option to read several channels quickly without keeping the system
busy doing just that.

I think I will try one program reading just one channel with periodic
task and comedi_data_read() and leave it running during the weekend.

Please tell me if there are any other types of test that could help.

Thanks again. Regards,

Vitor.

Received on 2004-03-24Z12:06:39