Hi The problem was more related to a memory leak what slowed the down the computer. This is fixed for now. For me performance means you can do your work during a period in time. So good performance means stay in realtime. cheers, Joël On Mon, Jul 20, 2015 at 2:43 PM, linuxball <linuxball@xxxxxxxxx> wrote: > Hi Joël, > > see remarks in the context below. > > Best regards, > > Wolfgang > > On 17.07.2015 22:05, Joël Krähemann wrote: >> >> Hi all, >> >> My name is Joël Krähemann, I'm developing: >> >> http://gsequencer.org >> >> and I'm using: >> >> Linux debian 4.0.5 #1 SMP PREEMPT Sat Jul 11 16:32:49 CEST 2015 x86_64 >> GNU/Linux > > From the output it seems that the kernel you are using is NOT a RT kernel > (otherwise "uname -v" should say "#1 SMP PREEMPT RT ..."). If you want to > use a RT kernel you should build the kernel with PREEMPT_RT_FULL defined. >> >> For now I encounter on my system performance problems at a load of 30 >> to 40 % system load, all 8 virtual cpu's have same average load. > > What do you mean when you talk about "performance problems"? How do they > manifest? > >> * `chrt` to higher priority doesn't give wished throughput. > > As you certainly know in general a RT kernel has worse throughput (but > better response times / lower latencies for time critical threads) than a > generic kernel. > >> * `taskset` has ff as default. >> * `cpufreq-set -g performance` brings a little improvement for first >> seconds >> >> This is my CPU: >> >> Architecture: x86_64 >> CPU op-mode(s): 32-bit, 64-bit >> Byte Order: Little Endian >> CPU(s): 8 >> On-line CPU(s) list: 0-7 >> Thread(s) per core: 2 >> Core(s) per socket: 4 >> Socket(s): 1 >> NUMA node(s): 1 >> Vendor ID: GenuineIntel >> CPU family: 6 >> Model: 58 >> Model name: Intel(R) Core(TM) i7-3740QM CPU @ 2.70GHz >> Stepping: 9 >> CPU MHz: 3275.648 >> CPU max MHz: 3700.0000 >> CPU min MHz: 1200.0000 >> BogoMIPS: 5387.58 >> Virtualization: VT-x >> L1d cache: 32K >> L1i cache: 32K >> L2 cache: 256K >> L3 cache: 6144K >> NUMA node0 CPU(s): 0-7 >> >> >> GSequencer uses many threads but doesn't stay in realtime. What am I >> doing wrong? Or how to gain more Performance out of the system? > > How do you define performance? If you want more throughput then try a > generic kernel. If you want shorter response times (lower latencies) for > selected RT threads than use a RT kernel and tweak the thread priorities of > the respective user and kernel threads in the processing chain. Make sure > that you don't get priority inversion by using improper RT prio assignment, > e.g. participating IRQ threads from kernel should have higher or same RT > prio than threads processing data delivered by those IRQ threads. A good > example for audio applications is > http://subversion.ffado.org/wiki/IrqPriorities which shows priority settings > for JACK audio applications. >> >> I could imagine on my code side that vary frequency segmentation would >> bring better throughput. By modeifing AGS_THREAD_DEFAULT_JIFFIE, >> AGS_THREAD_MAX_PRECISION and related. >> >> But for now I search for documentation about linux kernel performance >> counters. >> >> Best regards, >> Joël Krähemann >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" >> in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
