Re: cyclictest result variations

Re: cyclictest result variations

[Clark Williams]

On Wed, 28 Mar 2018 16:56:27 +0200
John Ogness <john.ogness@linutronix.de> wrote:

> On 2018-03-28, Phil Edworthy <phil.edworthy@renesas.com> wrote:
> >> > I found that cyclictest results vary from one run to another.
> >> >
> >> > [...]
> >> >
> >> > Is it common knowledge that cyclictest results vary so much from
> >> > one run to another? Any ideas how to mitigate this?  
> >> 
> >> It would be helpful if you provided the command arguments you use for
> >> your tests. Particularly important options to consider:
> >> 
> >>     -a / --affinity
> >>     -m / --mlockall
> >>     -n / --nanosleep
> >>     -t / --threads
> >>          --secaligned
> >> 
> >> and of course giving it an appropriate realtime priority:
> >> 
> >>     -p / --priority  
> >
> > Sure:
> > cyclictest   -m -n -Sp99 -i200 -h300 -M -D 10h  
> 
> I would recommend using prio 98 instead of 99. In general, applications
> should not be taking the CPU from the migration or watchdog tasks. And
> usually you want cyclictest to reflect the latencies of real
> applications.

Agree, please don't use fifo:99. Honestly there's no difference between fifo:51
and fifo:98. The interrupt threads default to fifo:50, so you want to be above that
but no real need to contend with migration, watchdog or posix timers. 

Also, if you are on a NUMA architecture system, you may want to use the
--numa/-U option, instead of the --smp/-S option. With that option cyclictest
uses the libnuma calls to allocate a stack on the local NUMA node for each
measurement thread (trying to avoid cross-node allocations). 

Clark