Experimental Physics and
Industrial Control System

From: "Johnson, Andrew N." <anj at anl.gov>
Date: Tuesday, 2 November 2021 at 16:30
To: Dirk Zimoch <dirk.zimoch at psi.ch>
Cc: EPICS Core Talk <core-talk at aps.anl.gov>, Timo Korhonen <Timo.Korhonen at ess.eu>, Ralph Lange <ralph.lange at gmx.de>
Subject: Re: [EXTERNAL] CA gateway chaining

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

 

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