Messages in this thread | | | Subject | Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4] | Date | Fri, 29 Oct 2004 21:06:41 -0400 | From | Paul Davis <> |
| |
>but i'd also suggest to put in a counter into that branch so that this >condition doesnt get lost. In fact the Maximum Process Cycle stat from >Rui: > >>> Maximum Delay . . . . . . . . . 6904 921 721 usecs >>> Maximum Process Cycle . . . . . 1449 1469 1590 usecs > >seems to suggest that there can be significant processing delays? (if >Maximum Process Cycle is indeed the time spent from poll_ret to the next >poll_enter.)
IIRC, Rui was running with -p128, which at 48000kHz is 2600usecs (and longer at 44100kHz). If the maximum process cycle was on the order of 1500usecs, that leaves nearly 1ms until the next interrupt is due. Unless jackd was held up between computing the process cycle time and entering poll, it doesn't seem that the process cycle ever gets close to the interrupt interval duration.
So I don't think that delays caused *during* jackd's processing cycle are involved here. However, I agree that your suggestion to check for this before computing max_delay is probably wise in general.
--p - 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/
| |