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

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

[mr. sindar]

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.

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

[Carsten Emde]

Sergey,

> [..]
> 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?  [..]
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.

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

[mr. sindar]

29/10/15 21:45, Carsten Emde:
> 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.
>
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

> 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.
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.