Messages in this thread | | | Date | Tue, 11 Jan 2005 22:21:39 +0100 | From | Ingo Molnar <> | Subject | Re: [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/
| |