Re: [Xenomai-help] Xenomai 2.5.6 with PPC-Kernel 2.4.25

[Philippe Gerum <rpm@xenomai.org>]

On Tue, 2011-06-21 at 16:05 +0200, Gilles Chanteperdrix wrote:
> On 06/21/2011 03:15 PM, Philippe Gerum wrote:
> > On Tue, 2011-06-21 at 15:05 +0200, roderik.wildenburg@domain.hid
> > wrote:
> >>> But more importantly, since, the time when we print the result is so
> >>> imprecise, some variations are normal, so, chances are that the 2%
> >>> variation is normal.
> >>>
> >>
> >> Ok. Here is a switchtest with Xenomai 2.4.9 on PPC-Kernel 2.4.25 and indeed fluctuation is again about 2%.
> >> But the number of context switches is just about 25% of switchtest from Xeno 2.5.6 on a PPC-2.6.34. Did you change the tasks period from 2.4.9 to 2.5.6?
> >> So, if the gurus say this variation is within the normal bandwidth it is ok for me.
> > 
> > The number of switches is related to the number of tasks running in this
> > test, nofpu reduces this number. So that is ok. The problem with this
> > test is that switches/sec values are sampled by a regular linux thread
> > which nanosleeps, so at least over 2.4, the delay is not accurate. So
> > the number of switches observed can't be either.
> 
> The task which nanosleeps does not really sample the number of context
> switches, it is part of the context switches chain, and simply prints
> the number when it sees that the last time the number was printed is
> more than 1s ago. So, how many context switches happen depends greatly
> on how many time the context switches chain passed by this task, and so
> is not regular.

This is why the sleeper actually samples somehow, polling then printing
the switch count from the driver based on a 1ms period it runs, given
that the scheduling chain should be reasonably fixed. Granted, this
cannot be precise at all in any case.

> 
> The switchtest code also changed between 2.4
>  and 2.6, which is why you
> can not compare the numbers.
> 
> Pay no attention to the number of context switches. All which matters is
> that this number increase over time, this is why we print them.
> 

And as a matter of fact, this is the good way to quickly detect the
kernel 2.4 issue we have.

-- 
Philippe.