Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: base max thread priority
From: Jeff Hill <johill@lanl.gov>
To: 'Eric Norum' <eric.norum@usask.ca>, 'Till Straumann' <strauman@SLAC.Stanford.EDU>
Cc: 'Marty Kraimer' <mrk@aps.anl.gov>, "'Johnson, Andrew N.'" <anj@aps.anl.gov>
Date: Tue, 26 Nov 2002 16:15:12 -0700
> RTEMS, and I expect vxWorks as well, have system
> tasks handling things like network I/O.  What priority should
> these run at?

You could argue that network activity should never disrupt database
processing and so the network threads should be run below the priority
of the EPICS scan tasks.

With the original vxWorks IP kernel we definitely saw problems when
certain activities occurred at a priority above that of the tNetTask.
However, I'm not sure that that "feature" still exists with the new
vxWorks SENS IP kernel.

If the interrupt message logger is run at the highest priority then it
seems that functions like logMessage() should only be called as a last
gasp, in a dire situation, if we are to avoid mysterious inadvertent
disruptions of important time critical processes. 

I recall hearing the story about how guests would walk in and command
something computationally intensive from the vxWorks shell at trade
shows with the unabashed purpose of forcing their vxWorks pin ball demo
to fail.

Jeff

> -----Original Message-----
> From: Eric Norum [mailto:eric.norum@usask.ca]
> Sent: Tuesday, November 26, 2002 3:10 PM
> To: Till Straumann
> Cc: Marty Kraimer; Johnson, Andrew N.; Jeff Hill
> Subject: Re: base max thread priority
> 
> 
> On Tuesday, November 26, 2002, at 04:03  PM, Till Straumann
> wrote:
> 
> >
> > Correct - but this could only happen if the insane task had a
> priority
> > > 91. However, if the user were to spawn a task with this
> high a
> > priority, he/she probably knew what he/she was doing: that
> task was
> > probably hard-rt critical and it was not tolerable to have it
> wait for
> > whatever
> > was going on at the console.
> >
> > IMO, clamping everyghing to < 91 with the shell running at 91
> is safe
> > - no runaway (base) task can lock the console. However, the
> user still
> > has the option of doing really critical work at a higher
> priority, if
> > necessary - at the risk of having a locked-up system should
> such a > task
> > run away, of course.
> > The benefit of leaving a range of priorities to the user IMO
> far
> > outweighs the possible damage.
> 
> Yes, running the shell at EPICS priority 91 seems reasonable.
> Now another question.  RTEMS, and I expect vxWorks as well,
> have system
> tasks handling things like network I/O.  What priority should
> these run
> at?  At the moment I've got the RTEMS network tasks at higher
> than the
> highest EPICS task priority.  From the above discussions it
> would seem
> that running the network tasks at an RTEMS priority equivalent
> to EPICS
> task priority 91 would be the right thing to do.
> Comments?
> 
> --
> Eric Norum <eric.norum@usask.ca>
> Department of Electrical Engineering
> University of Saskatchewan
> Saskatoon, Canada.
> Phone: (306) 966-5394   FAX:   (306) 966-5407


References:
Re: base max thread priority Eric Norum

Navigate by Date:
Prev: RE: base max thread priority Jeff Hill
Next: Re: base max thread priority Till Straumann
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: base max thread priority Eric Norum
Next: Re: base max thread priority Till Straumann
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·