with intel_pstate=disable the kernel falls back to the classical scaling_driver and governor 'ondemand':

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 
acpi-cpufreq

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors 
userspace conservative powersave ondemand performance

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
1827000 1826000 1660000 1494000 1328000 1162000 996000 830000 664000 498000

Pianoteq is showing the up and down freq-scalings under Perf>CPU then again.

The huge dropouts with the RT Kernel disappear with this scaling_driver and I'm quite sure, with the acpi-based 'cpufrequtils' it could be tweaked to performance too.

But for now, I'll stay with the standard (non-RT) Kernel and intel_pstate set to performance. It has a very good performance (powertop shows all 4 cores running at 2.2 GHz playing Pianoteq) and acpi-cpufreq seems to be deprecated on intel CPUs.

cheers

Strange though -- it appears those governors SHOULD now be gone in Fedora 20 according to this thread:

* https://ask.fedoraproject.org/en/questi...-governor/

It's possible the Supermicro bios has intel_pstate disabled.

Try adding to your RT kernel boot parameters:

* intel_pstate=disable

this is not specific to RT or non-RT Debian-Kernel. Both have this two governors available:

more /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors 
performance powersave

But there is a difference in usage: With the RT Kernel the scaling_governor is not writable:

# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 
bash: echo: write error: Invalid argument

I can only write it with the non-RT Kernel, as described in my previous posting.

What Bay Trail CPU are you running?

On my Bay Trail server running Fedora 3.14.9-200.fc20.x86_64, I get:

> more /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
> conservative userspace powersave ondemand performance

# governor performance
Setting core cpu0 to performance... 
Setting core cpu1 to performance... 
Setting core cpu2 to performance... 
Setting core cpu3 to performance...

# governor
Core cpu0 set to performance
Core cpu1 set to performance
Core cpu2 set to performance
Core cpu3 set to performance

I have placed it in my /etc/rc.local now for autostart.

Thanks a lot, delt!

Just running "governor" with no arguments will show you the current governor for each core. Running "governor performance" will set all cores to performance.

#!/bin/sh

cd /sys/devices/system/cpu
gov="$1"

if [ "$gov" = "" ]; then
  for core in cpu?; do
    echo -n "Core ${core} set to "
    cat ${core}/cpufreq/scaling_governor
  done
else
  if [ "`whoami`" != "root" ]; then
    echo "Root access is required for this operation. Trying sudo..."
    exec sudo "$0" "$@"
  fi
  for core in cpu?; do
    echo "Setting core ${core} to ${gov}... "
    echo "$gov" > ${core}/cpufreq/scaling_governor
  done
fi

I found the bottleneck! Intel_pstate just knows two different "governors" on my platform:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors 
performance powersave

Default ist 'powersave', but I changed that now quick & dirty with

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

Used from /etc/rc.local it is bootfix.

Together with the mainstream kernel 'linux-image-3.14-1-amd64' and ...

/etc/security/limits.conf:
@audio - rtprio 90
@audio - nice -10
@audio - memlock 500000

... I have a crackle-free, low-latency system now.

48000 Hz Sample rate
64 samples Buffer size (1.3 ms)
48 Maximum polyphony
Delay and reverb off
20 Performance index
around 30% Audio load

And the best: No spinning/moving parts in this baytrail netbook!

cheers

groovy wrote:

Sounds plausibel. But even on a weak AMD APU E-350 (1.6 GHz) I had a RT kernel running without any glitches in the past. So it comes unexpected, that a modern Intel Quadcore with 4 x 2.60 GHz (?!) has these massive problems. Ok, thanks for your explanations again, I'll stay tuned ...

Clock speed is only accurate when measuring the same CPU family.  For example, a 2GHz BayTrail faster than a 1.5GHz BayTrail but a 2GHz Pineview Atom is 3X slower.  In additional, you can split up CPU operations into multiple categories -- integer, floating point, SIMD, GPU (now since graphics are integrated in).  A CPU architecture can be fast in one category but slow in others.

Not to mention cache efficiency and pipelining. Modern CPUs rely heavily e.g. on pipelining: they load a whole string of instructions and try to run as many of them in parallel as possible (therefore even inside a single core you find parallel execution). This speeds up things considerably, since processor instructions can be quite different in terms of complexity (and thus many do not need a 'complete' CPU core to themselves). Context switching (i.e. between kernel and application or between applications) effectively kills the pipeline every time, and some CPUs' performance really sucks when this happens too often. Context switching also causes cache misses, making things worse. Then there is the register state that has to be saved/restored.

Long story short: context switching is trouble for the CPU and takes quite a lot of time. Because of all this, multitasking is a tradeoff: more frequent switching is more 'fair' but reduces efficiency, while less switching is more efficient but increases latency. And some CPUs are more sensitive than others.

Sounds plausibel. But even on a weak AMD APU E-350 (1.6 GHz) I had a RT kernel running without any glitches in the past. So it comes unexpected, that a modern Intel Quadcore with 4 x 2.60 GHz (?!) has these massive problems. Ok, thanks for your explanations again, I'll stay tuned ...

Clock speed is only accurate when measuring the same CPU family.  For example, a 2GHz BayTrail faster than a 1.5GHz BayTrail but a 2GHz Pineview Atom is 3X slower.  In additional, you can split up CPU operations into multiple categories -- integer, floating point, SIMD, GPU (now since graphics are integrated in).  A CPU architecture can be fast in one category but slow in others.

Historically, AMD has always been fast in integer + GPU but slow in floating point.  For most people, integer doesn't matter that much -- your browser opens internet websites pretty much the same speed on an ultraslow Atom versus an i7.  On the otherhand, floating point & SIMD shows its hand in games which people notice immediately.

So it seems wrong that "modern" CPUs can be slower than older ones but this is the dilemna facing Intel/AMD.  In the past, each new generation of CPUs would be 30% faster than the previous but they hit a single-threaded performance wall about 5 years ago so the fight has been moved to the bottom where the primary competition is ARM.  As slow as Bay Trail is compared to your classic desktops, ARM chips are even slower so it's all about how to make Bay Trail use even less power to fit into smartphones & tablets.

What this means is the E350 was only been "weak" compared to regular desktop CPUs.  Compared to its competition (Intel Atom line), it was 3X faster but also used 3X more power.  Basically, it's taken Intel 4 generations of Atom CPUs to match the overall performance of the E350 (specific integer/floating point/graphics/simd varying) while keeping the original 5W-8W power profile.  The same story for AMD but from the opposite direction -- 4 generations to keep roughly the same performance while pushing power down (5W for Mullins).

BTW, nice job of explanations, Kalessin.  Good thing I was asleep so you could write all the detailed replies before I saw the followup comments/questions.

groovy wrote:

... in my simple words: To do all those tricks, my computer comes under heavy load, which becomes so high, that all those tricks get worthless . It just gets overloaded and *predictable* stutters

Precisely. The realtime patches mean that the kernel actually does a lot more things a lot more often, and this increases the overhead considerably. And when the machine is not very fast, the increased overhead can result in effectively overloading the machine. It could even be that the 'apparent' CPU load is not that high, since kernel overhead is tricky to measure anyway... so it might not even look like the machine is under that heavy a load. When efficiency is important, the normal desktop kernel would be a better bet. The RT kernel is great when you pair it with a powerful machine: then you can use it to really minimise latency.

Sounds plausibel. But even on a weak AMD APU E-350 (1.6 GHz) I had a RT kernel running without any glitches in the past. So it comes unexpected, that a modern Intel Quadcore with 4 x 2.60 GHz (?!) has these massive problems. Ok, thanks for your explanations again, I'll stay tuned ...

groovy wrote:

The new Bay Trail celeron with 3.14.x-Kernel on the other hand does not have this file 'scaling_cur_freq'. Maybe due to the new scaling_driver 'intel_pstate'.

It looks like you are right: https://bugzilla.kernel.org/show_bug.cgi?id=57141 . So right now there is no convenient way to read the cpu freq on linux.. scaling_cur_freq does not exist with the intel_pstate governor, and cpuinfo_cur_freq can only be read by root. That's a bit sad.

Do not many modern CPUs use intel_pstate nowadays? I remember at least I saw this on a Samsung Notebook with Intel i5 ivy-bridge. If these internal frequency scalings are not so simple, as in the past any longer, it is maybe not so useful to show it in the frontend any longer. But the most important is, whether this has an hidden negative impact on the RT capabilities or not. I hope not ...

groovy: on the same machine?

No, the first one an old core2duo from Lenovo and the second one a new celeron N2930 ("Bay Trail") from Acer.

... in my simple words: To do all those tricks, my computer comes under heavy load, which becomes so high, that all those tricks get worthless . It just gets overloaded and *predictable* stutters

Precisely. The realtime patches mean that the kernel actually does a lot more things a lot more often, and this increases the overhead considerably. And when the machine is not very fast, the increased overhead can result in effectively overloading the machine. It could even be that the 'apparent' CPU load is not that high, since kernel overhead is tricky to measure anyway... so it might not even look like the machine is under that heavy a load. When efficiency is important, the normal desktop kernel would be a better bet. The RT kernel is great when you pair it with a powerful machine: then you can use it to really minimise latency.

The new Bay Trail celeron with 3.14.x-Kernel on the other hand does not have this file 'scaling_cur_freq'. Maybe due to the new scaling_driver 'intel_pstate'.

It looks like you are right: https://bugzilla.kernel.org/show_bug.cgi?id=57141 . So right now there is no convenient way to read the cpu freq on linux.. scaling_cur_freq does not exist with the intel_pstate governor, and cpuinfo_cur_freq can only be read by root. That's a bit sad.