Hi Carsten > As a role of thumb, the -i option is normally set to twice the expected > latency. If, for example you expect 100 us, set it to -i200. Your loop > end is then reached 50 times faster, or - what is much better - you may > specify 50 times more loops for a test of the same duration which > considerably increases the quality of your assessment. Normally, > however, you would probably wait for 100 million or even a billion loops. Thanks for the tipps, will try more sane values once i have a booting system again. Just testing non patched kernels. > With an average of 19 and a maximum of 27, the result is probably not > very relevant. This indicates that the CPU was idle most of the time > when the wakeup occurred - every OS can do this. The challenge of an > RTOS is to wakeup in time also when the kernel is not idle, e.g. from > kernel or driver code while a lock is held. Therefore, adequate stress > tools must be running during a latency measurement. As i mentioned i did tests on a imx31 with an older premptRT patch, and even Idle numbers where much worse. Probably due to the fact that arm support has just trickled in and is now more mature? > Please keep in mind that ftrace configured is not ftrace enabled. To > enable it, use cyclictest's -f option or execute > echo function >/sys/kernel/debug/tracing/current_tracer > echo 1 >/sys/kernel/debug/tracing/tracing_enabled > from command line. Again with my older tests only enabling tracing functionality made a significant performance hit. But well, its all moving in the right direction :-). Best regards Tim -- 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
