[lkml]   [2005]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PREEMPT_RT vs I-PIPE: the numbers, part 2

    * Paul E. McKenney <> wrote:

    > Any way of getting the logger's latency separately? Or the target's?

    with lpptest (PREEMPT_RT's built-in parallel-port latency driver) that's
    possible, as it polls the target with interrupts disabled, eliminating
    much of the logger-side latencies. The main effect is that it's now only
    a single worst-case latency that is measured, instead of having to have
    two worst-cases meet.

    Here's a rough calculation to show what the stakes are: if there's a
    1:100000 chance to trigger a worst-case irq handling latency, and you
    have 600000 samples, then with lpptest you'll see an average of 6 events
    during the measurement. With lrtfb (the one Karim used) the chance to
    see both of these worst-case latencies on both sides of the measurement
    is 1:10000000000, and you'd see 0.00006 of them during the measurement.
    I.e. the chances of seeing the true max latency are pretty slim.

    So if you want to reliably measure worst-case latencies in your expected
    lifetime, you truly never want to serially couple the probabilities of
    worst-case latencies on the target and the logger side.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-22 21:09    [W:0.021 / U:4.656 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site