1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Utilizing StreamDevice in conjunction with sockets |
From: | Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> |
To: | "'Wang, Andrew'" <wang126 at llnl.gov> |
Cc: | "Pogge, James Robert" <pogge1 at llnl.gov>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Tue, 18 May 2021 21:54:40 +0000 |
Ø
My startup file does not contain those two commands. If my understanding is correct, aren’t those for instruments containing serial ports? Unfortunately, the instrument
in question only has an ethernet. Ø
I am using 15 s for my timeout. The asynSetInputEos and asynSetOutputEos commands are not just for serial devices, they are for any devices that use the asynOctet interface, including TCP/IP, GPIB, etc.
Did you specify an input or output terminator in your protocol file? The large string you are sending to your device may include terminators within it (CR or LF), so you may not need asyn to add terminators. However, input is a different story. You have used this as the protocol for reading the response. in “:%s”; Because you have set noProcessEos=0 in drvAsynIPPortConfigure() then you are using the asynInterposeEos interface to read from the device. That means it will continue to try
reading from the device until one of the following is true: -
It gets the specified terminator. Because you have not specified a terminator in your st.cmd, then this will not happen unless perhaps you specified an input terminator
in your protocol file. -
It gets the requested number of input bytes. You have not specified a number of input bytes, so it will be the size of the array, and this condition won’t be met. -
It times out It seems to me that it is probably timing out waiting for the response. That could explain why it is taking 20 seconds compared to 5 seconds with a C program: 15 seconds of
the 20 is the timeout. Mark From: Wang, Andrew <wang126 at llnl.gov>
HI Mark, My startup file does not contain those two commands. If my understanding is correct, aren’t those for instruments containing serial ports? Unfortunately, the instrument in
question only has an ethernet. I am using 15 s for my timeout. Thanks, Andy From: Mark Rivers <rivers at cars.uchicago.edu>
Does your st.cmd contain these commands? asynOctetSetInputEos asynOctetSetOutputEos What timeout are you using in your protocol file? The output of asynTrace is likely to be more useful than perf. Mark From: Wang, Andrew <wang126 at llnl.gov>
Hi Mark, That is correct. It is a string, which contains information that the instrument needs such as what user input the command is directed at, checksum, etc. The response from the instrument will either be OK or ERROR, which will happen if the format of the command is wrong. Thanks, Andy From: Mark Rivers <rivers at cars.uchicago.edu>
Hi Andrew,
Ø
setCmd
Ø
{
Ø
out "%s";
Ø
in ":%s";
Ø
} So the very long command you are sending is a null-terminated ASCII string, and not binary data? What is the response from the device? Mark From: Wang, Andrew <wang126 at llnl.gov>
Hi Mark, Thanks for the reply. Here are some clarifications.
record(waveform, “inst_long_cmd") { field(DTYP, "stream") field(SCAN, "Passive") field(FTVL, "CHAR") field(NELM, 1970000) field(INP, "@inst.proto setCmd $(PORT)") field(FLNK, “another_rec”) } I have an asub record that creates the command which “inst_long_cmd” sends to the instrument via StreamDevice.
setCmd { out "%s"; in ":%s"; }
Thanks, Andy From: Mark Rivers <rivers at cars.uchicago.edu>
Hi Andrew, > There is one command that I need to send to the instrument occasionally that has a length of around 2000000 chars. > Based upon my observations, it takes about 20-30 seconds to send that command through a waveform record and receive a response back through StreamDevice. We need more information. What is the network interface speed on the device (100 MBit/s, 1 GBit/s, etc.). What is the asyn command you are using to create the asyn port? What does the definition of that waveform record in your database file? What is the Stream protocol you are using to send the waveform record data? > I was wondering if anybody has experienced similar behavior with StreamDevice for very long commands and how to potentially speed it up. I have used large waveforms with Stream on a few occasions, and I have not seen that Stream was slowing things down. > Should I investigate utilizing asyn or some other drivers, and if so, can it be run in conjunction with StreamDevice? If you are using Stream then you must already be using asyn as the underlying IP driver.
You should turn on asynTrace to look at the communications with the device, which will include timestamps. asynSetTraceIOMask myPort 0 HEX asynSetTraceMask myPort 0 DRIVER|ERROR You could easily write a little asyn port driver on top of that driver to send the data. But that is basically what Stream does, so it is surprising that it is slower than a C socket program.
If the above suggestions don’t offer a hint then you can run the IOC in a profiler like “perf” and see where it is spending its time. Mark From: Tech-talk <tech-talk-bounces at aps.anl.gov>
on behalf of Wang, Andrew via Tech-talk <tech-talk at aps.anl.gov> All, I’ve been using StreamDevice to interface EPICS with some of our instruments and I’ve noticed something interesting for quite some time now. There is one command that I need to send
to the instrument occasionally that has a length of around 2000000 chars. Based upon my observations, it takes about 20-30 seconds to send that command through a waveform record and receive a response back through StreamDevice. However, when I use sockets
in my C program, it takes about 3-5 seconds. Originally, what I wanted to do was somehow utilize sockets for just that command, while using StreamDevice for the rest of the commands. However, it doesn’t seem to work out since
once StreamDevice starts running, I am unable to use sockets in my asub record. I was wondering if anybody has experienced similar behavior with StreamDevice for very long commands and how to potentially speed it up. Should I investigate utilizing asyn or some
other drivers, and if so, can it be run in conjunction with StreamDevice? Ideally, it would be nice if I don’t have to migrate from StreamDevice since all the other commands work just fine. Thanks. Andy |