Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <core-talk at aps.anl.gov> · Tue, 2 Nov 2021 12:04:04 -0700

On 11/2/21 8:29 AM, Johnson, Andrew N. via Core-talk wrote:
> 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.

So... I feel compelled to point out that both iterations of a PVA gateway
which I have written are specifically designed to avoid the problem of
array PV subscription updates "starving" other.

> - 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 <mailto:core-talk-bounces at aps.anl.gov>> on behalf of EPICS Core Talk <core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>>
>>> Reply-To: Ralph Lange <ralph.lange at gmx.de <mailto:ralph.lange at gmx.de>>
>>> Date: Monday, 1 November 2021 at 16:18
>>> To: EPICS Core Talk <core-talk at aps.anl.gov <mailto: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 <mailto: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.
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System