Experimental Physics and
Industrial Control System

"jun-ichi.odagiri--- via Tech-talk" <tech-talk at aps.anl.gov> · Tue, 30 Mar 2021 14:09:52 +0900

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System