[PlanetCCRMA] kernel-rt latency issues

[Bob Wilkinson]

I apologise for the blank reply, I hit the wrong button.

At any rate, while the super-optimized version would be a nice niche, the fact is that I, like you Nando, use mine for a multitude of things - not just audio.  The compatibility is an acceptable compromise for an increase in some latency.

Later on in life, if I were to have a PC dedicated to recording, sitting in a studio and never left, then a super-optimized kernel would be ideal, but would it actually improve anything functionally?  With the speeds the modern multicore processors are running and the throughput the latest i/o is capable of, I doubt the improvement would be meaningful.

Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Fernando Lopez-Lezcano <nando at ccrma.Stanford.EDU>
Sender: planetccrma-bounces at ccrma.Stanford.EDU
Date: Wed, 07 Nov 2012 09:58:32 
To: Rob Wallace<rob.wallace at cae.com>
Cc: planetccrma at ccrma.stanford.edu<planetccrma at ccrma.Stanford.EDU>
Subject: Re: [PlanetCCRMA] kernel-rt latency issues

On 10/31/2012 08:28 AM, Rob Wallace wrote:
> Recently I’ve been evaluating the real-time PREEMPT_RT patch. I noticed
> that PlanetCCRMA already had RPM packages so I thought I would try them out.
>
> When I ran the ‘cyclictest’ on the ccrma kernel I noticed a lot of
> latency and jitter. This didn’t seem normal compared to the PREEMPT_RT
> kernel I built myself. After investigating the issue I found certain
> kernel options in the ccrma kernel that should not be selected for a
> real-time system.

Hi Rob and thanks for the feedback! (sorry for the delay in getting back 
to you, I was on a trip and then moving to a new house with very little 
time to pack, very very busy).

Do you have any results from the tests you did that compare your build 
and the one that I do for Planet CCRMA? I do use our builds for audio 
work and they seem to be working mostly fine.

As Tracey already mentioned I try to get the kernels I build to be as 
close as possible in terms of the options selected to the stock Fedora 
kernels (mostly for the sake of compatibility - you should be able to 
boot either and not run into any problems or unexpected behavior).

>These are the kernel options I changed to fix the
> latency issue in your build:
>
> # CONFIG_SUSPEND is not set
>
> # CONFIG_HIBERNATION is not set

Aha... these two would probably have to stay. I imagine most Planet 
CCRMA users would be interested at least in having suspend available, I 
do use that all the time in my laptop.

> # CONFIG_PM_RUNTIME is not set
>
> # CONFIG_PM_DEBUG is not set

I could probably do away with these two. That would lead to a rise 
(perhaps?) in power drain. It would be interested to know how much of a 
difference this makes, if any.

> CONFIG_ACPI_AC=m
>
> CONFIG_ACPI_BATTERY=m
>
> CONFIG_ACPI_BUTTON=m
>
> CONFIG_ACPI_FAN=m
>
> CONFIG_ACPI_PROCESSOR=m
>
> CONFIG_ACPI_THERMAL=m
>
> CONFIG_ACPI_CONTAINER=m

I don't know why these are set up as "y" in the Fedora kernel...

> # CONFIG_CPU_FREQ is not set
>
> # CONFIG_INTEL_IDLE is not set

Hmmm, again, probably I would have to keep these. So this affects 
latency even if you set the CPU governor to performance? (or set all 
CPUs to max speed with cpupower?)

> CONFIG_POWER_SUPPLY=m
>
> CONFIG_HWMON=m
>
> You can try a before and after test to see the difference. I ran the
> cyclictest as follows:
>
> cyclictest -a2 -m –n -I -i 100 -p 80

I'll look into these options in more detail when I have some free cycles...

It could be also an option to have a second build that is 
super-optimized for latency and darn the compatibility but I don't know 
if there would be much demand for it. Feedback welcome!

-- Fernando

_______________________________________________
PlanetCCRMA mailing list
PlanetCCRMA at ccrma.stanford.edu
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma