On Mon, 2011-01-31 at 12:17 +0100, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Mon, 2011-01-31 at 12:01 +0100, gryma biloy wrote: > >> On Mon, Jan 31, 2011 at 11:53 AM, Philippe Gerum <[email protected]> wrote: > >>> On Mon, 2011-01-31 at 11:51 +0100, Gilles Chanteperdrix wrote: > >>>> Philippe Gerum wrote: > >>>>> On Mon, 2011-01-31 at 09:55 +0100, gryma biloy wrote: > >>>>>> Hello, > >>>>>> > >>>>>> On a project running Linux on a beagle board, I'd like to add the > >>>>>> following capabilities to my platform : > >>>>>> - real time processes with periodic tasks (10ms, 100ms & 200 ms) and > >>>>>> a low jitter (< 50 us) > >>>>> Kernel space apps then, likely. Userland apps (the recommended way) > >>>>> probably have a larger worst-case jitter on this hardware, albeit still > >>>>> below 100 us. Gilles? > >>>> Las time I checked, latency measured on a 720MHz omap3 was around 55us > >>>> with a 1ms period and 35us with a 100us period. > >>> Yeah, I suspect that longer periods ( >= 10 ms ) may introduce more > >>> opportunities for cache eviction due to linux activity, and therefore > >>> higher jittery, even if bounded. > >> Does this mean that the main reason for jittery is due to the cache ? > >> What would be the other reasons, if any ? > > > > > > The main reason for more jittery with longer periods is due to the cache > > if you compare a high frequency loop and a lower one. When the rt system > > is idle, waiting for the next wakeup, the linux activity resumes and > > evicts a bunch of cachelines for running its own processes. So next time > > the rt system is resumed, a significant time will be spent refilling the > > cache with the rt program, starting with some real-time IRQ handler > > itself. This is why you always get better latencies when running a 10Khz > > sampling loop, than you would get for 1Khz. This can be observed on all > > archs Xenomai supports. > > > > On ARM, the memory subsystem is often involved in jittery for different > > reasons (ask Gilles why he implemented FCSE for instance). > > Well actually, this effect can not be observed on ARMv4/v6 without FCSE, > because the cache is flushed at each context switch. >
Unfortunately, we do have memory subsystem issues not directly involving tlb flushes and FCSE over v5. Typically, the lack of hw-assisted broadcasting of DMA operations with arm11/mpcore in SMP mode is a real pain as well. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
