Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rtscheduling

[Jack O'Quin]

Jack O'Quin <joq@xxxxxx> writes:
>
> I ran three sets of tests with three or more 5 minute runs for each
> case.  The results (log files and graphs) are in these directories...
>
>   1) sched-fifo -- as a baseline
>      http://www.joq.us/jack/benchmarks/sched-fifo
>
>   2) sched-iso -- Con's scheduler, no privileges
>      http://www.joq.us/jack/benchmarks/sched-iso
>
>   3) nice-20 -- Ingo's "nice --20" scheduler hack
>      http://www.joq.us/jack/benchmarks/nice-20

> I had some problems with the y2 graph axis (for XRUN and DELAY).  In
> most of the graphs it is unreadable.  In some it is inconsistent.  I
> hacked on the jack_test3_plot.sh script several times, trying to set
> readable values, mostly without success.  There is too much variation
> in those numbers.  So, be careful reading and comparing that
> information.  Some xruns look better or worse than they really are.

I fixed that problem in the script this way...

--- jack_test3_plot.sh~	Fri Jan 21 15:23:04 2005
+++ jack_test3_plot.sh	Sat Jan 22 21:21:58 2005
@@ -33,8 +33,8 @@
     set ylabel "CPU Load (%), CTX (x1000/sec)"
     set y2label "XRUN, DELAY (msecs)"
     set yrange [0:100]
-    set y2range [0:*]
-    set y2tics 0.2
+    set y2range [0:10]
+    set y2tics 2.0
     set terminal png transparent small size 640,320
     set output "${NAME}.png"
     plot \

Now it gives a consistent, readable range for the XRUN and DELAY data.
Anything over 10msec is "off the graph".  Successive graphs are easy
to compare visually.

I went back and regenerated yesterday's graphs from the original log
files with this change, so they're all consistent now for comparison
purposes.

> These tests were run without any other heavy demands on the system.  I
> want to try some with a compile running in the background.  But, I
> won't have time for that until tomorrow at the earliest.  So, I'll
> post these preliminary results now for your enjoyment.

I made more runs today with a compile of ardour running continuously
in the background.  These results were much more dramatic than
yesterday's lightly loaded system numbers.

My main conclusion is that on my system sched-fifo works almost
flawlessly, while neither nice-20 nor sched-iso hold up under load.

All the data are here...

  http://www.joq.us/jack/benchmarks/

in these six subdirectories...

  http://www.joq.us/jack/benchmarks/nice-20		   
  http://www.joq.us/jack/benchmarks/nice-20+compile	   
  http://www.joq.us/jack/benchmarks/sched-fifo	   
  http://www.joq.us/jack/benchmarks/sched-fifo+compile 
  http://www.joq.us/jack/benchmarks/sched-iso	   
  http://www.joq.us/jack/benchmarks/sched-iso+compile  

In many runs with both nice-20 and sched-iso, some of the test clients
failed to meet their deadlines and were evicted from the JACK graph.
This was particularly evident under load (see the nice-20+compile and
sched-iso+compile logs).  But, looking back at the logs from
yesterday, I see it also happened without the background compilation.
I didn't notice, because the effects were less obvious.  But, this may
explain the rather inconsistent results I noted at the time.

This run[1] shows a particularly dramatic example of this phenomenon.
Note the DSP load dropoff around second 140.  After that everything
runs fine because almost half of the clients were ejected.

  [1] http://www.joq.us/jack/benchmarks/nice-20+compile/jack_test3-2.6.11-rc1-q2-200501221908.png

There were *no* client failures in *any* of the sched-fifo runs.

So, I reluctantly conclude that neither of the new scheduler
prototypes performs adequately in its current form.  We should get
someone else to duplicate these results on a different machine, if
possible.

I'm wondering now if the lack of priority support in the two
prototypes might explain the problems I'm seeing.
-- 
  joq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/