EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 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: [EXTERNAL] CA gateway chaining
From: "Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>
To: Dirk Zimoch <dirk.zimoch at psi.ch>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Date: Tue, 2 Nov 2021 15:29:55 +0000
Rather than trying to do all that in one CA Gateway process, I would suggest running two Gateways with a Name Server in front of them, and it’s that which has the intelligence to direct the client to the appropriate Gateway server port for the channel. An initial version could make that decision based on a simple file with a list of array PV names in it, and you could later add more intelligence. That could even allow you to run multiple parallel Gateways if the load on one grows too large.

Instead of adding the kinds of things that Dirk suggests below to the existing Gateway, I would take a look at rewriting it using the IOC’s RSRV server which already supports multiple threads and doesn’t rely on the unmaintained GDD layer.

- Andrew


On Nov 2, 2021, at 8:49 AM, Zimoch Dirk (PSI) wrote:

Separating array data from scalar data manually is very work intensive. You need to identify naming patterns and still
have the risk that someone invents a new array with a name that is not matched by your filters.

But maybe the gateway can automatically move a connection to a separate CA context if it is an array? Depending on
whether the bottle neck is on the CA client or CA server side, this may be more or less complicated. If it is only the
server, the GW may run two servers, one that replies only when the channel turns out to be a scalar and the other that
replies only when the channel is an array. If the bottle neck is in the client, the GW would probably need to do the
connection twice, slowing down connection setup and increasing network load a bit for arrays: First do the normal search
request. On connect check the number of elements. If not 1, drop the channel and do again in a different context
reserved for arrays. (I do not think that you can "move" a ca connection from one context to another).

Does this sound feasible?
Will it help? I don't know.


On Mon, 2021-11-01 at 15:35 +0000, Timo Korhonen via Core-talk wrote:
Right, this is the way we are going for now. It is not exactly trivial to manage but should be doable.

Thanks,

TImo

From: Core-talk <core-talk-bounces at aps.anl.gov> on behalf of EPICS Core Talk <core-talk at aps.anl.gov>
Reply-To: Ralph Lange <ralph.lange at gmx.de>
Date: Monday, 1 November 2021 at 16:18
To: EPICS Core Talk <core-talk at aps.anl.gov>
Subject: Re: [EXTERNAL] CA gateway chaining

On Wed, 27 Oct 2021 at 10:49, Timo Korhonen via Core-talk <core-talk at aps.anl.gov> wrote:
Just a short follow-up.
We found out that the delays are due to large arrays being monitored over the gateway. Not a surprise, even if we
have tried to remind users about the effects with big arrays.


One way to mitigate this - I think this approach was implemented at some point at the SLS - is to route the large
array channels through a dedicated separate gateway instance.
(Ease of configuration depends on your naming convention.)

Cheers,
~Ralph


-- 
Complexity comes for free, simplicity you have to work for.


Replies:
Re: [EXTERNAL] CA gateway chaining Timo Korhonen via Core-talk
Re: [EXTERNAL] CA gateway chaining Michael Davidsaver via Core-talk
References:
CA gateway chaining Timo Korhonen via Core-talk
Re: [EXTERNAL] CA gateway chaining Hartman, Steven via Core-talk
Re: [EXTERNAL] CA gateway chaining Zimoch Dirk (PSI) via Core-talk
Re: [EXTERNAL] CA gateway chaining Timo Korhonen via Core-talk
Re: [EXTERNAL] CA gateway chaining Ralph Lange via Core-talk
Re: [EXTERNAL] CA gateway chaining Timo Korhonen via Core-talk
Re: [EXTERNAL] CA gateway chaining Zimoch Dirk (PSI) via Core-talk

Navigate by Date:
Prev: Re: [EXTERNAL] CA gateway chaining Zimoch Dirk (PSI) via Core-talk
Next: Re: [EXTERNAL] CA gateway chaining Timo Korhonen via Core-talk
Index: 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: [EXTERNAL] CA gateway chaining Zimoch Dirk (PSI) via Core-talk
Next: Re: [EXTERNAL] CA gateway chaining Timo Korhonen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 02 Nov 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·