[Xenomai-help] problems solved

[Xenomai-help] problems solved

[Steven Seeger]

Well, I solved my problems by getting rid of the geode. On a 400 mhz celeron
board, everything works great. My software used 100% of the CPU on the geode
and locked up the Linux side when the stepper motor would run, but on the
celeron it uses a negligible amount of the CPU. This is good for me to see
that the problem isn't with my code probably, but bad that Xenomai seems to
have issues on the Geode that RTAI/fusion did not.

Just giving you all a heads up. The geode sucks anyway.

Re: [Xenomai-help] problems solved

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

Steven Seeger wrote:
> Well, I solved my problems by getting rid of the geode. On a 400 mhz celeron
> board, everything works great. My software used 100% of the CPU on the geode
> and locked up the Linux side when the stepper motor would run, but on the
> celeron it uses a negligible amount of the CPU. This is good for me to see
> that the problem isn't with my code probably, but bad that Xenomai seems to
> have issues on the Geode that RTAI/fusion did not.
> 
> Just giving you all a heads up. The geode sucks anyway.
> 

Well, this "it used to work" doesn't satisfy me. Maybe Geode is
revealing some subtle bug that only triggers under certain load
scenarios. That's why it would be really great if you could try to nail
the issue a bit more down with the suggested steps. When e.g. the tracer
then shows that your code "hangs" on some inb/outb for too long, we can
be sure that this is a hardware-related issue.

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-help] problems solved

[Jeroen Van den Keybus]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

Have you tried loading the Celeron to 100% as well ? Remember that,
depending on where your interface resides, inb/outb access to the PCI bus
or, even worse, the LPC, may be stalled by heavy traffic on the CPU
front-end bus or the MCH-ICH link.

Just giving you all a heads up. The geode sucks anyway.


Let's cross fingers for the poor Celeron that your software
never outgrows it.

BTW, what board were you using ? I'm asking because I may be able to get a
Geode here for testing but all processors may not be the same.


Jeroen.

[-- Attachment #2: Type: text/html, Size: 836 bytes --]

Re: [Xenomai-help] problems solved

[Philippe Gerum]

Steven Seeger wrote:
> Well, I solved my problems by getting rid of the geode. On a 400 mhz celeron
> board, everything works great. My software used 100% of the CPU on the geode
> and locked up the Linux side when the stepper motor would run, but on the
> celeron it uses a negligible amount of the CPU. This is good for me to see
> that the problem isn't with my code probably, but bad that Xenomai seems to
> have issues on the Geode that RTAI/fusion did not.

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.

> 
> Just giving you all a heads up. The geode sucks anyway.
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] problems solved

[Steven Seeger]

> 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? I get garbage data from the
latency teests. When I tried to disable periodic mode in configuration I get
an ENODEV on module insert.

Steven

Re: [Xenomai-help] problems solved

[Philippe Gerum]

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.

Re: [Xenomai-help] problems solved

[Steven Seeger]

That particular post didn't work for my board. I tried it when posted. :)

Thanks though.

Steven

On 2/24/06 8:00 AM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> Philippe Gerum wrote:
>> (...) making sure that no SMI source is active. (...)
> 
> Note that SMI workaround whether with RTAI/Fusion, with Xenomai 2.0 or
> Xenomai 2.1 does not work for all Geode boards.
> 
> a workaround for disabling SMI on some Geode boards was posted on RTAI
> mailing list:
> https://mail.rtai.org/pipermail/rtai/2005-July/012391.html

[Xenomai-help] problems solved

[Steven Seeger]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

So, my CPU usage problems with tasks were due to my heavy use of mutex
recursion. I got it for free in the kernel, so it made sense to do the
same in userspace. But, syscall overhead was a big problem so I wrapped
them with a simple class that seems to have solved the issue.

 

The reason I have a lot of mutex recursion is that there are many layers
of functions that talk to certain pieces of hardware, and you may call
them at the top or at the bottom. So, the mutex must be protected at
every step.

 

This change reduced a 2ms periodic task from 25% cpu usage down to about
16.7%. A 22% usage 500 us periodic task was reduced to 15%. These two
tasks work together to move and control a stepper motor and read all of
its sensors and inputs. The same functionality in the old system with
RTAI used about 25% of the CPU as measured by RTAI's stats stuff.
(Perhaps this wasn't very accurate.) So I'm very pleased with the
results, and feel there can probably be further optimization. (Obviously
we expect some overhead in userspace.) This usage is down from over 50%
CPU usage between the two tasks.

 

Steven

 

 


[-- Attachment #2: Type: text/html, Size: 3439 bytes --]