From: "mr. sindar" <npc.sindar@gmail.com>
To: Carsten Emde <C.Emde@osadl.org>, linux-rt-users@vger.kernel.org
Subject: Re: Variscite VAR-SOM-AM33 with patch-3.12.10-rt15
Date: Fri, 30 Oct 2015 11:08:12 +0300 [thread overview]
Message-ID: <5633256C.9090109@gmail.com> (raw)
In-Reply-To: <56326932.3090206@osadl.org>
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.
prev parent reply other threads:[~2015-10-30 8:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 8:38 Variscite VAR-SOM-AM33 with patch-3.12.10-rt15 mr. sindar
2015-10-29 18:45 ` Carsten Emde
2015-10-30 8:08 ` mr. sindar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5633256C.9090109@gmail.com \
--to=npc.sindar@gmail.com \
--cc=C.Emde@osadl.org \
--cc=linux-rt-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).