Re: Changing EPICS general Purpose Thread's Priorities

["jun-ichi.odagiri--- via Tech-talk" <tech-talk at aps.anl.gov>]

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