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
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
message4 VALUE
And sometimes like:
message1 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.