Variscite VAR-SOM-AM33 with patch-3.12.10-rt15

Hello. I need some help or maybe just advice of right use of realtime-kernel. We are(company where i work) now developing PLC based on Variscite VAR-SOM-AM33 processor module(http://www.variscite.com/products/system-on-module-som/cortex-a8/var-som-am33-cpu-ti-am335x-am3354-am3352). Variscite provides it with kernel version 3.12. I've patched it with patch-3.12.10-rt15 and chose Full Preemptible Kernel(RT) preemption model. As result when i run cyclictest(like said in wiki - https://rt.wiki.kernel.org/index.php/Cyclictest) with no other load in system, i've got following results:
cyclictest -t1 -p 80 -n -i 10000 -l 10000
System without RT-patch:
T: 0 ( 1399) P:80 I:10000 C: 10000 Min: 35 Act: 69 Avg: 63 Max:

    247
System with RT-patch:
T: 0 ( 1534) P:80 I:10000 C:  10000 Min:     39 Act:   61 Avg:   61 Max: 
     91

So it works.

But when i enable load with codesyscontrol-system(about 80% CPU load), i have following results:
System without RT-patch:
T: 0 ( 1412) P:80 I:10000 C: 10000 Min: 8 Act: 16 Avg: 13 Max:

    572

System with RT-patch:
T: 0 ( 1549) P:80 I:10000 C: 10000 Min: 11 Act: 14 Avg: 17 Max:
2492
Is it normal that max jitter in system with RT-patch more(almost 5x time) than in system without RT-patch, in this case?
Sorry, if this question silly. I've used only DOS-like(one-task) systems earlier and wrote firmwares with one task only in embedded systems, and Linux only on desktop and servers, without realtime. Thanks, in advance.

Best regards, Sergey.

Sergey,

Is the codesyscontrol system running at priority above 80 or below? If above, then at least the second result makes sense, since on a single-core system only the one task that runs at highest priority is the real-time task that enjoys the worst-case latency of the system. All other tasks do not. If, however, priority 80 of the cyclictest task is the highest priority of all tasks, then you may have detected a problem that needs to be fixed.

Note that cyclictest is intended as a placeholder of a real-time task for people who do not have their own user-space real-time project, for example kernel developers and board manufacturers. Once you have your own real-time application, you better equip it with internal real-time checks in a similar way as cyclictest does it, but you should not run cyclictest in parallel.

Thanks,
-Carsten.

29/10/15 21:45, Carsten Emde:

I executed codesyscontrol without setting any priority and scheduling policy. When i execute chrt -p <pid_of_codesyscontrol>, it shows:
pid 1532's current scheduling policy: SCHED_OTHER
pid 1532's current scheduling priority: 0
But now i think it wasn't true. After your advice i execute cyclitest with maximum priority(99), and results became deterministic. ./cyclictest -t1 -p 99 -n -i 10000 -l 10000

# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 4.95 4.39 2.80 2/77 1533
T: 0 ( 1533) P:99 I:10000 C:  10000 Min:     13 Act:   20 Avg:   20 Max: 
     62

The real goal for me, indeed, is running codesyscontrol, which is runs IEC 61131-3 industrial programs.
First i tried codesyscontrol run on Linux without RT-patch. It was sporadic multiplying of cycle time of IEC 61131-3-program. And then i decide to try RT-patch. But multiplying of cycle time in CodeSys is still appears, even when it runs with 99 priority. So now i think it's a problem in CodeSys runtime system(as i convinced with your advice, that RT-patch works well), i wrote this issue to their support(because we are buying binary package of CodeSys, i can't do with this any programming hacks, but only administrative).

Thank You very much for help!

Best regards, Sergey.