Re: [Xenomai-help] problems solved

[Philippe Gerum <rpm@xenomai.org>]

Steven Seeger wrote:
>>Again, the only way to make your point here would be to run the latency test
>>in 
>>user-space, disabling the periodic timing at configuration level (v2.1 only),
>>and 
>>making sure that no SMI source is active. If the results actually show
>>performance 
>>degradation on this board between v2.0 (which is based on the latest fusion
>>code) 
>>and v2.1-rc3, then your conclusion would have more weight.
>>
> 
> 
> Didn't we already figure out that my geode board won't run the latency tests
> because it doesn't support aperiodic mode?

No, we didn't. Geode is no different than any other x86 platform Xenomai-wise, and 
it does obviously support the aperiodic mode; actually all platforms Xenomai 
currently runs on do support aperiodic mode, which is the fundamental one, only 
the periodic mode is optional. When CONFIG_X86_UP_APIC is off, this mode is 
obtained by programming the 8254 PIT in a different way than it is done for the 
periodic one, but it's exactely the same hardware involved; the rest is purely 
software-based. Incidentally, I'm running an MDB acquisition system on a Geode 
266Mhz board, right now, on my desk, just in front of me, so unless I'm badly 
hallucinating, your board should work too.

The key is to go back to a sane setup: first a properly configured kernel for this 
kind of board (no SMI, no APIC, no PM, USB host-side driver enabled), 2.6.14 or 
2.6.15 with -ipipe 1.2-00 or later would do. Then, proper Xenomai configuration: 
basically the default one + SMI detection enabled; during performance measurement, 
you should also leave the nucleus watchdog off unless you really need this for 
debugging. Unless you have a lot more than a handful of threads that actually 
compete for the CPU (i.e. they might be in a runnable state, concurrently, and 
most of the time), the O(1) scheduler is clearly overkill and uselessly increases 
the memory footprint without buying you anything compared to the linear one. It's 
mainly intended for applications that might need a large number of actually 
concurrent threads.

  I get garbage data from the
> latency teests.

This garbage is expected: the latency test _must_ work in aperiodic timing mode; 
what you've been seeing is the effect of jitter accumulation, tick after tick, 
since the periodic mode does not allow to follow a precise timeline by adapting 
the delay between ticks and thus compensate for the past jittery.

  When I tried to disable periodic mode in configuration I get
> an ENODEV on module insert.
> 

Make sure that CONFIG_XENO_OPT_TIMING_PERIODIC is off and 
CONFIG_XENO_OPT_TIMING_PERIOD is 0. The former should imply the latter, but this 
is not the case yet; will fix.

> Steven
> 


-- 

Philippe.