![]() | |||||||||||||
Messages in this thread |
* Karim Yaghmour <karim@opersys.com> wrote: > Ingo Molnar wrote: > > how were interrupt response times measured, precisely? What did the > > target (measured) system have to do to respond to an interrupt? Did you > > use the RTC to measure IRQ latencies? > > The logger used two TSC values. One prior to shooting the interrupt to > the target, and one when receiving the response. Responding to an > interrupt meant that a driver was hooked to the target's parallel port > interrupt and simply acted by toggling an output pin on the parallel > port, which in turn was hooked onto the logger's parallel port in a > similar fashion. We'll post the code for all components (both logger > and target) for everyone to review. There's no validity in any tests > if others can't analyze/criticize/ duplicate. ok, this method should work fine. I suspect you increased the parport IRQ's priority to the maximum on the PREEMPT_RT kernel, correct? Was there any userspace thread on the target system (receiving the parport request and sending the reply), or was it all done in a kernelspace parport driver? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-06-12 06:42 [W:0.953 / U:0.030 seconds] ©2003-2008 Jasper Spaans | |||||||||||||