EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: flaky IOC problems at Jefferson Lab
From: [email protected]
To: [email protected]
Date: Wed, 08 Jan 97 10:46:58 -0500
(response to Marty's comments)

>Chip has also requested that CA gets/puts also have priorities. (I think
>I recall this also being discussed previously by Jeff and others.)
>This means multiple priority CA server tasks.
>Should any of these priorities be higher than any of the scan tasks?

Should be user configurable. I.e., 3 priorities (high, medium, low) with the
priorities of those servers configurable with respect to the priorities of
the proposed High, Medium, Low scan tasks.  My first guess would be to 
interleave them (SCAN, CA, SCAN, CA, SCAN, CA).  If we used only a single
server I would configure as (SCAN, CA, SCAN, SCAN), so that the application
developer has a place to put his semi-hard requirements above channel
access activity.

>2) Setting CA UDP and CA TCP to high priority.
>
>This is not a good way to solve the slow connection problem.
>Processing CA search requests can, for short periods of time,
>put a significant load on an IOC. This make it extremely
>difficult or impossible for the application developer
>to test that the performance requirements are meet.
>I seems strange that a high priority real time requirement for
>an IOC is to make a new operator screen quickly connect.
>If this was truly a time critical screeen why wasn't to already
>up and running when it was needed?

Operator response is a high priority requirement for all screens, and there
are too many to keep up all the time.  To address your concern, and still
keep the performance, there are two solutions:

1) move name resolution off to another (redundant) process on Unix; probably
   configurable so those who don't want to manage their namespace don't have
   to.

2) use the CA gateway to front most or all clients, and have the gateway
   have LONG timeouts on dropping an unused channel.  This unloads most of 
   the connect and monitoring load off of the ioc, making it more real
   time

The second option is pretty much available today, and the first has been
discussed for several years at low priority.

Chip


References:
Re: flaky IOC problems at Jefferson Lab Marty Kraimer

Navigate by Date:
Prev: Re: flaky IOC problems at Jefferson Lab watson
Next: PC/WIN32 Display Options Kay-Uwe Kasemir
Index: 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: flaky IOC problems at Jefferson Lab Marty Kraimer
Next: Re: flaky IOC problems at Jefferson Lab Bill Brown
Index: 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·