On Mon, 8 Oct 2007, Jaswinder Singh wrote: > Hello Robert, > > On 10/8/07, Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx> wrote: > > On Sun, Oct 07, 2007 at 06:20:29PM +0530, Jaswinder Singh wrote: > > > I am also getting : > > > root@rd 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 > > > [root@rd 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 > > > [root@rd 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
