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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.