-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Apr 2009 18:22:01 +0200
Tim Sander <tstone@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi
> > Have you tried cyclictest? It's part of the rt-tests package that
> > Thomas Gleixner wrote and that I now maintain.
> I think cyclictest is nice to get some first impressions and i really like
> it... but it only give the aggregate.
Well, I think it's more useful than first impressions, but I'm biased :)
>
> > The thing is, I'm not sure how useful measuring the interval between
> > interrupt and ISR. It's such a small component of the total latency
> > value that it usually gets lost in the noise.
> I don't think that you can neglect these numbers in a hard rt environment.
> As far as i understand, the irq-tasklet has to be scheduled by the kernel.
What I mean is that the latency from interrrupt signal to system ISR is
so small that you'd be better off trying to reduce some of the other
components to try and reduce total latency.
Of course I don't have any hard numbers on how small the ISR latency is
compared to scheduling the IRQ thread and scheduling the user-thread
that was waiting for the interrupt event. I wonder if there are any
markers already in the RT kernel that would let us measure those
components? That way we could argue concrete numbers rather than just
abstract ideas.
I'll ask rostedt...
> > If you are wanting to decompose the latency into it's components on RT,
> > I think you'd have:
> > 1. ISR latency
> > 2. Scheduler latency for IRQ thread
> > 3. IRQ handler time
> > 4. Scheduler latency for user-space thread
> > Cyclictest measures the aggregate of all these.
> One good aproach to minimize user mode latency are probably user mode drivers.
> This approach has been presented at the Embedded in Nürnberg this year by
> linutronix. So you can shave off #2 of the above list. Which means only one
> rescheduling runs instead of two. Usermode has of course to be run with rt
> priority.
>
Yeah, but you're limited to polling the h/w at that point. Good if you
have a spare core and a high data rate, bad if you're cpu-limited and
have a sporadic data rate.
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
iEYEARECAAYFAknmAW8ACgkQHyuj/+TTEp08DACfYADnFL1BSDfgEr3tZjS8qFGU
udMAoKqp2bRO6F/tZOODmEYCzkk0LDFd
=1O2L
-----END PGP SIGNATURE-----
ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·¥?{±þ»ÿºÇ«³ø§¶?¡Ü¨}©?²Æ zÚ&j:+v?¨þø ¯ù ®w¥þ?à2?Þ?¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ?ú+?ù???Ý¢jÿ?wèþf
