Thank you, I think your considerations are the right ones. The DMA controller is not generating any interrupt, so I assume it is not actually working. I'm trying to verify that the jitter is caused by cache/TLB misses. I don't have much reference on how to lock the cache, so I'll just try to have the cache dirty in any other way to see if it causes the same jitter.
Antonio On Mon, Sep 22, 2008 at 11:15 AM, Fillod Stephane < [EMAIL PROTECTED]> wrote: > Antonio Del Cinque wrote: > [...] > >Then I open an ssh connection with the target, and run a "cat /dev/zero > > file". The target > >is mounted on an NFS root filesystem, so this generates a high number > of > >fast ethernet interrupts. Now the oscilloscope shows 15 uS jitter in > the worst case, > >and a visible variance. I would assume this effect as increased max > latency. > > This figure has already been seen with SoC in the range of the e300, > and sometime worse. > > >The ethernet interrupt is handled only in Linux domain by the original > vanilla handler, > >but Linux should be stalled/preempted when the timer interrupt occurs. > So I assume > >that latency is to be justified by the time it takes to adeos to record > an > >ethernet interrupt event in the i-logs when the timer interrupt is > executing or ready to > >execute. Is this correct? > > Cache miss and TLB miss are also good latency killers. > To some extent, long DMA transfers can bog down the system bus. > > >Is there any way to lower max latency for the timer interrupt? > > Has anybody tried to play with cache locking? > > -- > Stephane >
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
