Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Paul Davis <paul@linuxaudiosystems.com>]

>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