lkml.org 
[lkml]   [2005]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] [request for inclusion] Realtime LSM

    * Jack O'Quin <joq@io.com> wrote:

    > The numbers I reported yesterday were so bad I couldn't figure out why
    > anyone even thought it was worth trying. Now I realize why.
    >
    > When Ingo said to try "nice -20", I took him literally, forgetting
    > that the stupid command to achieve a nice value of -20 is `nice --20'.
    > So I was actually testing with a nice value of 19. Bah! No wonder it
    > sucked.
    >
    > Running `nice --20' is still significantly worse than SCHED_FIFO, but
    > not the unmitigated disaster shown in the middle column. But, this
    > improved performance is still not adequate for audio work. The worst
    > delay was absurdly long (~1/2 sec).
    >
    > Here are the corrected results...
    >
    > With -R Without -R Without -R
    > (SCHED_FIFO) (nice -20) (nice --20)
    >
    > ************* SUMMARY RESULT ****************
    > Total seconds ran . . . . . . : 300
    > Number of clients . . . . . . : 20
    > Ports per client . . . . . . : 4
    > Frames per buffer . . . . . . : 64
    > *********************************************
    > Timeout Count . . . . . . . . :( 1) ( 1) ( 1)
    > XRUN Count . . . . . . . . . : 2 2837 43
    > Delay Count (>spare time) . . : 0 0 0
    > Delay Count (>1000 usecs) . . : 0 0 0
    > Delay Maximum . . . . . . . . : 3130 usecs 5038044 usecs 501374 usecs
    > Cycle Maximum . . . . . . . . : 960 usecs 18802 usecs 1036 usecs
    > Average DSP Load. . . . . . . : 34.3 % 44.1 % 34.3 %

    what kind of non-audio workload was there during this test? 43 xruns
    arent nice but arent that bad either.

    plus, is it 100% sure that all audio threads inherited the nice --20
    priority - including the client threads? Nornally jackd does a
    setscheduler for the client threads so that they get boosted to
    SCHED_FIFO, but there is no parallel to that in the nice --20 case, did
    you do that manually (or did you start the clients up from the nice --20
    shell too?))

    If the nice --20 priority setup is perfect and there are still xruns
    then could you try the following hack, change this line in
    kernel/sched.c:

    #define STARVATION_LIMIT (MAX_SLEEP_AVG)

    to:

    #define STARVATION_LIMIT 0

    this will turn off starvation checking, for testing purposes. (to see
    whether there's anything else but anti-starvation causing xruns.)

    Ingo
    -
    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:09    [W:0.027 / U:1.784 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site