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. Also, I recommend adding "--secaligned". This will align cyclictest to the Linux ticks to possibly provide a more consistent worst case scenario. You could provide a secaligned offset to purposely avoid the Linux ticks, but avoiding a known bad case should only be done if a real application would be able to do that also. John Ogness -- 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
