[PlanetCCRMA] kernel-rt latency issues

[Rob Wallace]

Hi Fernando,

I had a lot of results from the original CCRMA kernel but I've since updated my notes with the results from my custom CCRMS kernel. As I recall the results were dramatic. In some cases the basic Linux kernel was more deterministic under load. Of course this depends on your requirements. If you're running under 500Hz chances are you won't notice a thing. Push the frequency over 4000Hz and you will overrun quite frequently. The cyclictest command I provided runs at 10000Hz (-i 100).

To be honest I'm not sure which option made the most difference. I compared my config file with yours and set those options as a 'good guess' so I can't say which one had the most impact. I assume it's the CONFIG_CPU_FREQ and CONFIG_INTEL_IDLE. It takes a while to compile the kernel so I didn't bother to narrow down the problem any further. Let me know if you determine the exact options.

Rob

-----Original Message-----
From: Fernando Lopez-Lezcano [mailto:nando at ccrma.Stanford.EDU] 
Sent: November 7, 2012 12:59 PM
To: Rob Wallace
Cc: 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