[PlanetCCRMA] The results of my not so great tests

Fernando Lopez-Lezcano nando@ccrma.Stanford.EDU
Wed Dec 29 16:20:04 2004


On Wed, 2004-12-29 at 15:46, fonse006 wrote:
>      The way that I tested them was I took a cue from someone else on this 
> list, I forget who it was, used jack and ardour to record 4 audio tracks each 
> with four plugins.  Three of the tracks were just background noise, but the 
> fourth was a midi track that I used to vary the cpu load.  What I will report 
> is the lowest latency that I was able to achieve under each kernel with the 
> base tracks running in ardour and myself not raising the cpu load and I will 
> report how high I had to raise the cpu load in order to get xruns.
> stock 2.6.9smp-
> latency- 5.33 msec,  xrun-cpuload-about- 65-70%
> 2.6.9-2.2.rdt.rhfc2.ccrmasmp
> was not tested as jack crashed 4 times in a row within 30 seconds of opening
> unless I turned realtime off, it did not matter whether I used jackd or 
> jackstart
> 2.6.9-2.2.rdt.rhfc2.ccrma
> latency- 0.667 msec, xrun-cpuload- 55-60%

You mean total 0.667msec (16 sample buffers) or input/output only (32
sample buffers)? In either case I'm surprised it works at all!

> 2.6.10smp
> latency- 2.67 msec,   xrun-cpuload- 90-95%
> 2.6.10-
> latency- 2.67 msec,  xrun-cpuload- 85%
> 2.6.7-1.437.1.ll.rhfc2.ccrmasmp-
> latency- 10.7 msec,  xrun-cpuload- 65%
> 
> analysis:
>      I think that the easiest thing to say is that things are looking up for 
> the 2.6 kernel version.  Currently I think that the most usable system is 
> 2.6.10 (that is if you are willing to run all of your audio software as root, 
> which is not a good idea as a bad bug could bring your system to its knees), 

That is very interesting, I just read a post by Lee Revell saying that
he also had had good results with plain 2.6.10. Obviously I will build
packages asap, it should be a LOT less risky to run than the highly
optimized realtime preemption patched kernels :-)

Hopefully once people return from vacation we may see a port of the
realtime preempt patch to plain 2.6.10... the best of both worlds!

> but the reatime-preempt patch delivers one quarter the latency, but there does 
> seem to be some overhead involved in using the realtime-preempt patch as the 
> base level cpuload for the realtime preempt patch was much higher than the 
> rest (quite a bit more that I would expect from just transferring samples 4 
> times as often. 

It would be interesting to see what cpu load you get from running the
rdt kernel with the same latency as the 2.6.10 case, and whether that
makes it more stable. I'm not surprised at the increase in cpu use, you
were running with extremely low buffer sizes, I don't think at that
point you will see linear increases in cpu usage, it will be more like
exponential. 

> Also at least on my system the something in that kernel makes 
> the system a lot less stable.  Ardour crashed like 3 times while I was doing 
> the test, but not at all with any of the other kernels.  For all I know though 
> this could be a problem with ardour. 

No, probably problems with the kernel itself. But I would try with
higher latencies, the comparison would be more fair. 

> Anyway, I think that is all that I had 
> to say besides that these were very bad tests.  They are not in anyway 
> scientifically valid.  I only did one test with each kernel and did not test 
> more than one latency level with each kernel.  Those are just the two problems 
> with my tests that come to mind right of the top of my head.  Results may 
> vary.  

Sure. 
But a very useful test nevertheless!
Keep us informed of any extra tests...
-- Fernando