Re: Exploring EPICS performance/processing limits

["Marco A. Barra Montevechi Filho via Tech-talk" <tech-talk at aps.anl.gov>]

Hi, Hu! Thanks for the hint.

Since issue is that im trying to use a transform record to do several operations in sequence and im only using python to understand the IOC's capacity of processing several record values changes quickly, i think cothread is more of a diagnostics tool in this case than a fix to the problem.

I did follow your instructions nonetheless and the results were somewhat similar to expected. Here is the script:

#!/usr/bin/python3

import cothread

from cothread.catools import caput

caput(["MOBICDTE:Backend:ImgChipNumberID", "MOBICDTE:Backend:ImgChipNumberID",

    "MOBICDTE:Backend:ImgChipNumberID", "MOBICDTE:Backend:ImgChipNumberID"], [0, 1, 2, 3])

The tcpflow results skip both "params": [["1","1"]] and "params": [["1", "2"]] commands:

127.000.000.001.55780-127.000.000.001.60000: {"id":"1", "method":"HS_ImgChipNumberID_Command", "params": [["1", "0"]], "jsonrpc": "2.0"}

127.000.000.001.55780-127.000.000.001.60000: {"id":"1", "method":"HS_ImgChipNumberID_Command", "params": [["0"]], "jsonrpc": "2.0"}

127.000.000.001.55780-127.000.000.001.60000: {"id":"1", "method":"HS_ImgChipNumberID_Command", "params": [["1", "3"]], "jsonrpc": "2.0"}

127.000.000.001.55780-127.000.000.001.60000: {"id":"1", "method":"HS_ImgChipNumberID_Command", "params": [["0"]], "jsonrpc": "2.0"}

And the camonitor didnt even show any signal. Nothing at all. Same as if i had just typed the camonitor command and did no operation at all with the PV:

camonitor MOBICDTE:Backend:ImgChipNumberID

MOBICDTE:Backend:ImgChipNumberID 2022-10-06 15:24:16.416637 3 READ INVALID

CA.Client.Exception...............................................

    Warning: "Identical process variable names on multiple servers"

    Context: "Channel: "MOBICDTE:Backend:ImgChipNumberID", Connecting to: 192.168.55.1:5064, Ignored: s-mgn-mob01-l.abtlus.org.br:5064"

    Source File: ../cac.cpp line 1320

    Current Time: Thu Oct 06 2022 15:26:07.987693022

..................................................................

---

From: Hu, Yong <yhu at bnl.gov>
Sent: 06 October 2022 10:33
To: Marco A. Barra Montevechi Filho <marco.filho at lnls.br>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Exploring EPICS performance/processing limits

 

Hello Marco,

To me, looping with “caput_one_pv_at_a_time” seems inefficient, especially in the Python world where “list” is a daily-usable data structure.

I have been using another Python-based Channel Access tool named “cothread” where you simply caput a list of pvs associated with a list of values: cothread.catools.caput(pvs, values). In your case, cothread.catools.caput(a_list_of_records, VALUE, repeat_value=True).

I have used “cothread” in one application where I get ~200 BPM waveform data (100K doubles per BPM) in a few seconds by caget(bpm_wavform_pv_list). Basically the processing time is dominated by the limited network bandwidth. “cothread” is very efficient by using cooperative threading.

Take a look at these links:
https://github.com/dls-controls/cothread
https://cothread.readthedocs.io/en/latest/catools.html#cothread.catools.caput

Cheers,
Yong

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Marco A. Barra Montevechi Filho via Tech-talk <tech-talk at aps.anl.gov>
Date: Wednesday, October 5, 2022 at 7:26 PM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Exploring EPICS performance/processing limits

Hello all.

I bumped into something that may or may not be caused by EPICS default processing time limits and would like tips on how to explore it, if possible.
I have a set of records that send messages to a loopback ethernet address via a .proto file and stream device.
Lets say RECORD1 sends a string "message1 VAL1", RECORD2 sends "message2 VAL2", etc.

I was monitoring the traffic with ´tcpflow -c -i <my_IP> port <my_PORT> | grep "message"´ and made a python script in the form:

import epics, time
def do_thing(x):

    for record in ["RECORD1", "RECORD2", "RECORD3", "RECORD4"]:

        epics.caput(record, VALUE)

        time.sleep(x)

The messages i got from tcpflow when executing the python script with do_thing(1.5) were nicely formatted:
message1 VALUE
message2 VALUE
message3 VALUE
message4 VALUE

But when i do the same thing with x=0.5, messages 2 and 3 were sometimes missing or sometimes badly formatted. Sometimes i got things like:
message1 VALUE

message2

message3

message4 VALUE

And sometimes like:

message1 VALUE

message4 VALUE

 

Is this a PV processing time issue? Shouldnt the IOC be capable of dealing with time intervals smaller than this? Is there a way i can improve this behaviour without setting sleep times between my caputs?

Thanks in advance,

Marco

 

Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.