EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Changing EPICS general Purpose Thread's Priorities
From: Jeong Han Lee via Tech-talk <tech-talk at aps.anl.gov>
To: jun-ichi.odagiri at kek.jp
Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Tue, 30 Mar 2021 16:48:18 -0700
Dear Odagiri-san,

Does your PLC-bus require a device-specific kernel module? If this is
the case, you should check this kernel module's priority by using the
method, which Kukhee's previous email and that priority should be
higher than all EPICS priorities. There is a script that I used for
this purpose in [1].

I assume that you use "irqbalance" service in your Linux system as
well even if you have PREEMPT_RT patch.

Best,
Han

[1] https://github.com/icshwi/realtime-config/blob/master/rtprio.bash

On Mon, Mar 29, 2021 at 10:10 PM jun-ichi.odagiri--- via Tech-talk
<tech-talk at aps.anl.gov> wrote:
>
> Dear Han-san,
>
> > * Is your Linux is a real-time kernel?
>
> Yes, PREEMPT_RT patch has been applied.
> But USE_POSIX_THREAD_PRIORITY_SCHEDULING is still the default value of
> NO. So, IOC threads have not yet been scheduled in a real-time fashion.
> I am going to change it to YES.
> I'm also going to call mlockall() in the xxxApp/src/xxxMain.cpp to make
> the IOC program memory resident.
>
> But I now think that my problem is not a real-time issue as I wrote
> in the previous mail. Having said that, I am going to make the IOC
> real-time to be on the safe side.
>
> > * which way do you communicate with many PSC? A dedicated network
> > connection? The same (as your IOC) ethernet connection? USB? FireWire?
> > * do you have a specific kernel driver for this connection?
>
> Our IOC is PLC-based.
> A CPU module running Linux reads/writes registers of a master
> controller on the PLC-bus. Then, the master controller sends
> commands and gets responses from many slave cards embedded in
> the power supplies under control. The field bus that connects
> the master PLC module and the slave cards is not standard one
> but home-made one.
>
> > We've had some discussion on this issue on the Core-talk, you may see
> > the solution which you want to find in there
> >
> > https://epics.anl.gov/core-talk/2021/msg00143.php
>
> I will take a look at the site.
> By the way, what is the "Core-talk"? That's new to me.
>
> Lots of thanks for your attention.
>
> Best regards,
>
> J.Odagiri at KEK
>
>
> ----- Original Message -----
> > Dear Odagiri san,
> >
> > * Is your Linux is a real-time kernel?
> > * which way do you communicate with many PSC? A dedicated network
> > connection? The same (as your IOC) ethernet connection? USB? FireWire?
> > * do you have a specific kernel driver for this connection?
> >
> > We've had some discussion on this issue on the Core-talk, you may see
> > the solution which you want to find in there
> >
> > https://epics.anl.gov/core-talk/2021/msg00143.php
> >
> > HTH,
> > Han
> >
> >
> > On Sat, Mar 27, 2021 at 12:36 AM jun-ichi.odagiri--- via Tech-talk
> > <tech-talk at aps.anl.gov> wrote:
> > >
> > > Dear William,
> > >
> > > Thank you for your comment,,, but sorry, I did not understand
> > > the meaning of the "multiple callback threads" solution.
> > > Would you tell me about it a little bit more in detail?
> > >
> > > Best regards,
> > >
> > > J.Odagiri at KEK
> > >
> > >
> > > ----- Original Message -----
> > > > A few other ideas is that you can try multiple callback threads or
> > > > splitting into multiple IOCs.
> > > >
> > > > On Sat, Mar 27, 2021, 2:32 AM jun-ichi.odagiri--- via Tech-talk <
> > > > tech-talk at aps.anl.gov> wrote:
> > > >
> > > > > Dear Ralph
> > > > >
> > > > > Thanks for your reply.
> > > > >
> > > > > > Changing priorities of callback, driver or communication
> threads
> > > with
> > > > > > respect to database processing.
> > > > > >
> > > > > > Which is exactly what your question is about.
> > > > >
> > > > > I got it. Thanks!
> > > > >
> > > > > > Why do you want to change the priority of "CAS-TCP"? Note that
> > > this is
> > > > > not
> > > > > > a "general purpose thread", but one of the core threads of the
> > > Channel
> > > > > > Access server.
> > > > >
> > > > > Here is the reason.
> > > > >
> > > > > An IOC controls many power supplies of something. The IOC is
> polling
> > > the
> > > > > status of the power supplies at a SCAN rate of 0.1 seconds. When
> the
> > > > > number of the power supplies increases, the IOC starts to lose
> > > commands
> > > > > sent from an CA-client. I thought that the problem would be
> solved
> > > if
> > > > > I give the "CAS-TCP" a priority which is higher than that of "
> scan-0.
> > > 1".
> > > > >
> > > > >
> > > > > But, on the second thought, I realized that there is no need to
> do
> > > that
> > > > > because the commands sent from the CA-client will be queued on
> the
> > > IOC-
> > > > > side.
> > > > > As far as some time is left for the "CAS-TCP" to run, the loss
> of
> > > > > commands
> > > > > should not occur.
> > > > >
> > > > > Am I right?
> > > > >
> > > > > I guess the origin of the problem would not be an issue of
> priority
> > > but
> > > > > an issue of throughput. So, I decided to solve the problem by
> > > improving
> > > > > the efficiency of the polling of the status of the power
> supplies.
> > > > > Fortunately, there is a way to do that.
> > > > >
> > > > > >     The default priorities of the EPICS IOC threads are well-
> > > chosen.
> > > > > They
> > > > > > have been proven to ensure reliable IOC operation and
> > > communication,
> > > > > in
> > > > > > many installations, under a variety of circumstances.
> > > > >
> > > > > I am really aware of this. That is the reason why I noticed my
> > > > > misunderstanding
> > > > > of the situation.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > J.Odagiri at KEK
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > > On Fri, 26 Mar 2021 at 08:09, jun-ichi.odagiri--- via Tech-
> talk <
> > > > > > tech-talk at aps.anl.gov> wrote:
> > > > > >
> > > > > > > Here is my question.
> > > > > > >
> > > > > > > Can I change the priority of "CAS-TCP" thread and "scan-10"
> > > > > > > thread so that the former is given a higher priority than
> > > > > > > that of the latter without modifying any source files in
> > > > > > > base?
> > > > > > >
> > > > > > > Does the site you guided me to answer the question?
> > > > > > >
> > > > > >
> > > > > > As per the README of the MCoreUtils, one of its features is
> > > > > >
> > > > > > Changing priorities of callback, driver or communication
> threads
> > > with
> > > > > > respect to database processing.
> > > > > >
> > > > > > Which is exactly what your question is about.
> > > > > >
> > > > > > The MCoreUtils facility allows rule-based manipulation of
> thread
> > > > > > properties, so that things like changing a priority will apply
> to
> > > all
> > > > > > threads with a name matching a specific pattern, whenever they
> > > will be
> > > > > > created on that IOC.
> > > > > >
> > > > > > Why do you want to change the priority of "CAS-TCP"? Note that
> > > this is
> > > > > not
> > > > > > a "general purpose thread", but one of the core threads of the
> > > Channel
> > > > > > Access server.
> > > > > > (From the MCoreUtils documentation:)
> > > > > > Warning
> > > > > >     The default priorities of the EPICS IOC threads are well-
> > > chosen.
> > > > > They
> > > > > > have been proven to ensure reliable IOC operation and
> > > communication,
> > > > > in
> > > > > > many installations, under a variety of circumstances.
> > > > > >     Manipulating the real-time properties, especially
> scheduling
> > > > > policies
> > > > > > and priorities, may have unwanted side effects. Use this
> feature
> > > > > sparingly,
> > > > > > and test well.
> > > > > >
> > > > > > Cheers,
> > > > > > ~Ralph
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

References:
MRF kernel module, failed to map BARS GAGET Alexis via Tech-talk
Re: MRF kernel module, failed to map BARS Michael Davidsaver via Tech-talk
RE: MRF kernel module, failed to map BARS GAGET Alexis via Tech-talk
Changing EPICS general Purpose Thread's Priorities jun-ichi.odagiri--- via Tech-talk
Re: Changing EPICS general Purpose Thread's Priorities Jeong Han Lee via Tech-talk
Re: Changing EPICS general Purpose Thread's Priorities jun-ichi.odagiri--- via Tech-talk
Re: Changing EPICS general Purpose Thread's Priorities Ralph Lange via Tech-talk
Re: Changing EPICS general Purpose Thread's Priorities jun-ichi.odagiri--- via Tech-talk
Re: Changing EPICS general Purpose Thread's Priorities William Layne via Tech-talk
Re: Changing EPICS general Purpose Thread's Priorities jun-ichi.odagiri--- via Tech-talk
Re: Changing EPICS general Purpose Thread's Priorities Jeong Han Lee via Tech-talk
Re: Changing EPICS general Purpose Thread's Priorities jun-ichi.odagiri--- via Tech-talk

Navigate by Date:
Prev: Re: Question on Multiple Instruments in one IOC or Multiple IOCs for each Hu, Yong via Tech-talk
Next: Re: Questions about arrays Ben Franksen via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
Navigate by Thread:
Prev: Re: Changing EPICS general Purpose Thread's Priorities jun-ichi.odagiri--- via Tech-talk
Next: Re: Changing EPICS general Purpose Thread's Priorities Kim, Kukhee via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 31 Mar 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·