On Wed, 28 Mar 2018 16:56:27 +0200 John Ogness <john.ogness@xxxxxxxxxxxxx> wrote: > On 2018-03-28, Phil Edworthy <phil.edworthy@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
