On Mon, 8 Oct 2007, Jaswinder Singh wrote:
> Hello Robert,
>
> On 10/8/07, Robert Schwebel <[EMAIL PROTECTED]> wrote:
> > On Sun, Oct 07, 2007 at 06:20:29PM +0530, Jaswinder Singh wrote:
> > > I am also getting :
> > > [EMAIL PROTECTED] cycletest]# ./cyclictest -t 1 -p80 -n -i 10000 -l 10000
> > > -q
> > > T: 0 ( 2709) P:80 I:10000 C: 10000 Min: 8 Act: 16 Avg: 16 Max:
> > > 44
> > > [EMAIL PROTECTED] cycletest]# ./cyclictest -t 1 -p80 -i 10000 -l 10000 -q
> > > T: 0 ( 2723) P:80 I:10000 C: 10000 Min: 21 Act: 30 Avg: 29 Max:
> > > 139
> > > [EMAIL PROTECTED] cycletest]#
> >
> > Doesn't look too bad.
>
> 139 microseconds interrupt latency looks not too bad for Genral purpose OS.
>
> But this is still bad in Realtime point of view.
Sigh. Realtime is not as fast as possible, it's as fast as
specified. It depends on your requirements whether it is sufficient or
not.
Also cyclictest is not about interrupt latency, it's about the full
chain of:
timer interrupt
scheduler
user space execution
in the second test you did it's:
timer interrupt
softirq + signal delivery
scheduler
user space execution
The softirq processing is causing the longer latency here.
This problem is known and it can be fixed, but it's not high
on the priority list.
Thanks,
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
