Hi, > When I compare this results with: > > http://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch > > it should be possible to get worst case latency below 150 us (for this kind of > processor). The problem with this page is that there are no details, about the > test environment. Was it measured with cyclictest? Was there anything running in Well, those seem to be my measured figures, so I will try to explain them. It is _not_ measured with cyclictest. The worst case latency here is determined by: 1: a periodic interrupt of which the handler runs in IRQF_NODELAY domain. 2: A user space thread running as SCHED_FIFO at prio 99 that goes to sleep and that is woken up directly by the periodic interrupt handler with wake_up_process(). (the posix_cpu_timers thread is pushed down to 98 so only 1 thread is running at 99) 3: The user space thread toggles a GPIO line 4: With a scope the wost-case time is measured between the interrupt generation and the moment the GPIO toggles. With a optimal configured kernel it is even possible to reach latency times in user-space close to about 40-50us, it is merely limited by the time a cache flush takes due to process context switching. But in practice the 150us is a nice figure to calculate with in a environment like this. The lower the priority of your realtime thread is set, and the more softirqs/irq-threads are prioritised above it, the higher the latencies count up. So, cyclictest will likely not reach these kind of figures, because it is highly dependant on the OS timer framework, and on softirqs/interrupts. IIRC those were in the 500us area... The fun is that system load does not have much impact on the worst case figures, it only increases the chance the worst case figures occur. These numbers are measured on 2.6.23-rt and 2.6.24-rt quite some time ago. I have no figures yet on how 2.6.31-rt behaves now. But, I have not found any real stability problems so far, except the serial terminal problem with shared interrupts that is solved by using irqf_nodelay for this interrupt handler. Kind Regards, Remy -- 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
