lkml.org 
[lkml]   [2004]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]
    Date
    From
    >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/

    \
     
     \ /
      Last update: 2005-03-22 14:07    [W:4.476 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site