lkml.org 
[lkml]   [2004]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm2-V0.7.30-2
    From
    Florian Schmidt wrote:

    > Ingo Molnar wrote:
    >
    >> > Just made some test-runs with RT-V0.7.30-2, with my jackd-R +
    >> > 8*fluidsynth benchmark on my laptop (P4/UP), and the results don't
    >> > seem to be eligible to the hall of fame, at least when compared with
    >> > RT-0.7.7 as the ones I last posted here a few weeks ago.
    >> >
    >> > I hate to say this, but the XRUN rate has increased since RT-0.7.7,
    >> > and the maximum scheduling delay reported by jackd has also degraded
    >> > to 1000 usecs (was around 600 usecs).
    >>
    >> well, life would be too easy if two bugs were fixed at once ;)
    >
    > Hi,
    >
    > i just wanted to mention that a good share of jack clients have issues
    > themself, doing all kinds of funky stuff in the RT thread which they
    > shouldn't do. Maybe the RP kernel just exposes this misuse in a greater
    > visible way. I don't know if fluidsynth is one of them. We could only find
    > out by code inspection.
    >

    Yes, I know all this, and I warned before that this tests were strictly
    and specific to the hardware, jackd and fludisynth code which are
    intentionally kept the same along the several RT kernels that have been
    issued.

    Note that I've kept this consistency to my self, and applies /only/ to my
    laptop, where the tests are being evaluated. Again, this test-suite of
    mine has the sole intention to compare the jackd workload performance
    across kernels, in an almost real softsynth scenario. All kernels tested
    are built with no debug options, ressembling production ones as far as
    possible.

    For example, these are the results-du-jour, which serves as a straight
    comparison RT-V0.7.30-2, with the previous posted ones from RT-V0.7.7:

    RT-V0.7.7 RT-V0.7.30-2
    --------- ------------
    XRUN Rate . . . . . . . . . . : 45.6 292.0 /hour
    Delay Rate (>spare time) . . : 43.2 265.3 /hour
    Delay Rate (>1000 usecs) . . : 3.6 29.3 /hour
    Delay Maximum . . . . . . . . : 1249 1045 usecs
    Cycle Maximum . . . . . . . . : 946 1127 usecs
    Average DSP Load. . . . . . . : 55.2 60.1 %
    Average CPU System Load . . . : 13.2 15.5 %
    Average CPU User Load . . . . : 41.9 46.2 %
    Average CPU Nice Load . . . . : 0.0 0.0 %
    Average CPU I/O Wait Load . . : 0.1 0.1 %
    Average CPU IRQ Load . . . . : 0.0 0.0 %
    Average CPU Soft-IRQ Load . . : 0.0 0.0 %
    Average Interrupt Rate . . . : 1675.4 1673.8 /sec
    Average Context-Switch Rate . : 13940.9 14894.7 /sec

    The only thing that has changed here was the kernel image, as everything
    else has remained constant.


    > Another way to test a more complex scenario than just jackd running with
    > an empty graph (assuming that jackd itself isn't to blame) while avoiding
    > the risk of getting bad data due to insane clients would be to code up an
    > example jackd client that does nothing but putting some load onto the
    > jackd graph but in a strictly RT fashion (no blocking stuff whatsoever).
    >
    > Attached you probably find the most minimal jack client thinkable that
    > does nothing but copy data from its input to its output port. Its only
    > parameter is the time in seconds it will run (default 60). The jack client
    > name is determined by the PID, so it can be started multiple times (jackd
    > requires a unique name for each client).
    >
    > compile with
    >
    > g++ -o jack_test jack_test.cc -ljack
    >
    > This code can easily be adapted to produce more load (just do some math
    > stuff with the data in the process callback).
    >
    > It seems jackd has a limitation to 14 clients atm (don't ask me why). The
    > 15th kills jackd ;)
    >

    So true.

    > Also i wanted to mention that a good share of ALSA drivers have issues,
    > too, and aren't nessecarily suited to low latency audio work. I don't know
    > how to rule these out except for using the ALSA dummy soundcard driver
    > (which might have its own issues, but it's probably simple enough to work
    > reliable. it just doesn't use any hw IRQ's so it's maybe not a good
    > measure for what we want to test) or to use a soundcard with a proven good
    > driver.
    >

    Of course, and the "reference" driver used on my tests is no exception
    (snd-ali5451). But again, it's been kept the same on all tests, and the
    improvement along the progression of the RT kernel development has been
    outstanding nevertheless.

    Cheers.
    --
    rncbc aka Rui Nuno Capela
    rncbc@rncbc.org

    -
    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:08    [W:4.493 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site