Package Details: rtapp 0.6.8-1

Git Clone URL: (read-only)
Package Base: rtapp
Description: Realtime application thread priority tuning
Upstream URL:
Licenses: custom
Submitter: blackhole
Maintainer: blackhole
Last Packager: blackhole
Votes: 5
Popularity: 0.000005
First Submitted: 2015-01-24 15:45
Last Updated: 2018-03-09 15:35

Dependencies (5)

Required by (1)

Sources (1)

Latest Comments

1 2 3 Next › Last »

blackhole commented on 2018-03-09 15:25

Ok, I will fix this as soon as possible.

capoeira commented on 2018-03-09 15:10

rtirq configuration moved from /etc/conf.d/rtirq to /etc/rtirq

blackhole commented on 2017-02-14 18:49

Updated rtapp.conf

jrdnjhntn commented on 2016-09-29 18:16

that makes sense (as a very quick test, i guess).

I wonder though, rather than suggesting the c-state flags, maybe it would be worthwhile to offer suggestions that are less (potentially) harmful/dangerous? Personally, I would never give someone that advice, as I've done tests and watched within just a few minutes of torturing my system that I have gotten dangerously high cpu temp using intel_idle.max_cstate=0...then, I imagine leaving it that way for hours, or being someone who isn't monitoring sensors. O_o

I mean there are better ways to improve latency/determinism on -rt, then using the c-state flags. Examples; using cpu affinity and cpu isolation, disabling hyper-threading, etc... Steven Rostedt has a pretty good talk on youtube discussing some of this stuff; ... It doesn't get super-specific, but does give a nice overview, while also dispelling some of the myths surrounding PREEMPT_RT systems...

another option is to limit some of the deeper c-states, while not setting it to =0, which might be a nice compromise for some people. Another option that could be used (in combination with limiting c-states) is to tweak intel_idle a bit, as Clear Linux does;

personally, i dont think that the intel_idle.max_cstate=0 flag is needed, if you have tuned your system/apps for RT. It's cost outweighs it's benefit, imho.

blackhole commented on 2016-09-28 07:50

Substantially I agree with you...

My little test is very useful when I must quickly check realtime systems just after installation. Moreover, good audio systems must have very few applications running (and eventually I must check only audio ones).

I would add something more. Using hqplayer with oscilloscope test there is also one more check: the sound. If the system has some problems the sound output will have dropouts or noises. This can happen also with async dacs if the processor is not up to the task, with the numbers given by the various tests apparently good.

For absolutely max processor latency performance (if PC has an absolutely very good cooling system) I can add
intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll intel_pstate=enable
to kernel line (not good in the summer...)

jrdnjhntn commented on 2016-09-28 07:13

@blackhole - ya, i have rt-tests installed already and I was the person/maintainer who introduced tuna into Archlinux/AUR (and packaged it's deps.) before I handed over the package to jhernberg...

I'll take a look at hqplayer, but I'm pretty sure that I already have better test-cases to be running with hackbench/cyclictest. I have a few scripts kickin around that launch highly multi-threaded apps (using rtprios) and/or videos in sequences, etc...

jrdnjhntn commented on 2016-09-28 07:02

@blackhole - I'll take a look at the rtcheck again tmrrw. Sounds good, if it is fixed. :-)

about STRESS TEST: I'm fairly familiar with hackbench and cyclictest (i've been using them for years), so I understand the results ~ That's not the problem. The problem is that your stress test is artificial and gives a false impression of what the system's max: latency is going to be in real world usage.

For example; throw nvidia driver into the mix - open multiple videos in a browser and watch what happens.. your max: latency will likely spike giving you no latency guarantees or determinism whatsoever ...another example, introduce other CPU intensive RT tasks into the mix or launch a VM...again, your max: latency will likely spike/increase... cyclictest and hackbench are great, but you have to run them for hours and hours with other stuff going on to have any idea of what your system is really capable of on -rt...

about: intel_idle.max_cstate=0 - ya, it will reduce latency, since ur avoiding going into deeper c-states ~ but i'm not sure that's really a great solution to be recommending to people. It can also be a great way to cook your CPU, if ur unlucky or not paying attention.

blackhole commented on 2016-09-28 06:32

For a more complete "latency" stress test (this is not a simple cpu load test) I suggest to install tuna and and rt-tests and launch

bash -c "cyclictest -t1 -n -p99 -i100 -o10 -v | oscilloscope -s1000 >/dev/null"

and at the same time launch hqplayer with PCM --> DSD upsampling

blackhole commented on 2016-09-28 06:19

Version 0.6.6 is out, with rtcheck fixed
Inside rtcheck there is a little stress test (it is not very stressing...). The simple code is

echo "
cyclictest -l $loop -n -m -Sp98 -i100 -d0

echo "
hackbench -l $loop &
cyclictest -l $loop -n -m -Sp98 -i100 -d0

You can interpret the results like this:
1) STRESS TEST more or less equal to STANDARD TEST --> your system is fine.
2) STRESS TEST give much higher numbers than STANDARD TEST --> your processor is inadequate
3) STRESS TEST give much lower numbers than STANDARD TEST --> your processor latency is not good in normal use, you can fix this adding for example intel_idle.max_cstate=0 to the Grub or Syslinux kernel line etc.

This has been conceived for testing using at the same time some "extreme" audio applications (see hqplayer) with real time upsampling from PCM to DSD (up to DSD512)

jrdnjhntn commented on 2016-09-27 23:44

I just thought that I would point out the your rtcheck program doesn't detect the presence of PREEMPT_RT properly;

--> Is your kernel realtime?

kernel name: 4.6.7-rt13-3-rt_plus
*** This is not a realtime kernel

$ uname -a
Linux nine7x 4.6.7-rt13-3-rt_plus #1 SMP PREEMPT RT Tue Sep 27 15:39:23 EDT 2016 x86_64 GNU/Linux
(...and kernel .config = CONFIG_PREEMPT_RT_FULL=y)

realtimeconfigquickscan (standard tool for checking a linux system for realtime audio)
perl ./, result;
Kernel with Real-Time Preemption... found - good
I didn't even look at what your code does to detect a realtime kernel, but it doesn't seem to work correctly.. 0_o
***EDIT: I see/looked at your script. It just searches to see if it ends in rt.

if [[ $kernel_name == *rt ]]; then
echo "This is a realtime kernel"

...ya, i think that is a pretty bad/lazy check. the realtimeconfigquickscan script actually checks the kernel config for PREEMPT_RT_FULL=y ... which, imho, is the proper way to check.
I'm also curious about the 'stress test' of rttest; hackbench aside, I'm not really sure how effective it is as a legit 'stress-test', unless I am missing something here. could you explain? ...

I think that while you DO need some cpu load, you also probably need to simulate some actual (potential) interruptions in order to see how they affect your max: latency numbers - to be meaningful. (maybe your script also shouldn't exit either, until it prints the final results).