- From: Frank Mori Hess <fmhess_at_users.sourceforge.net>
- Date: Thu, 25 Mar 2004 18:41:40 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 24 March 2004 07:06 am, Vitor Angelo wrote: > 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 This is probably due to a race between the end-of-scan interrupt being handled and the dma transfer of the scan data completing. For a while, I had some code in the interupt handler that tried to busy wait to make sure the scan's data had been transferred. But I had misgivings about putting a delay loop in an interrupt and took it out. I'll probably put something back in to deal with this. > > 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. > I don't think the driver is causing your 1msec disabling of RT. The driver only disables interrupts briefly while reading/writing to windowed registers (and during comedi_poll() but that locking was just added and you had this problem before). - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFAY2425vihyNWuA4URAnzvAJ9tHv5e+kYGQw9zph2Azryeu/4OvgCff/LN z+xjYH8m7/jrS5u2trfSZvY= =Ay67 -----END PGP SIGNATURE-----
Received on 2004-03-25Z23:41:40