[PlanetCCRMA] The results of my not so great tests

[fonse006]

>===== Original Message From Fernando Lopez-Lezcano <nando at ccrma.Stanford.EDU> 
=====
>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!
>
Just to make sure I tested again and received basically the same results I got 
xruns at 50% cpuload (this could have been because I had an irc client going 
though).  It was a 32 sample buffers.  Jack worked with 16, but I could not 
get ardour to start at that setting.  Now when I say that it worked, I mean 
that only that there were no problems with recording.  As soon as turn on jack 
the system response goes to hell, because all of the extra SCHED_FIFO tasks 
are starving the I/O tasks for processor cycles.  This might even be why 
ardour crashes I don't know, I am not very good at debuging.  I should not 
really speculate 'cause I don't know enough. This last time my whole system 
bit it.

>> 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.
>

I will test this tomorrow and let you all know what I get, for the moment I am 
fed up with ardour crashing. I was wondering though how other people were 
doing with the smp rdt kernel. 
Adam


>> 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
>
>
>_______________________________________________
>PlanetCCRMA mailing list
>PlanetCCRMA at ccrma.stanford.edu
>http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma