RE: Utilizing StreamDevice in conjunction with sockets

["Wang, Andrew via Tech-talk" <tech-talk at aps.anl.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>
Sent: Monday, May 17, 2021 2:54 PM
To: Wang, Andrew <wang126 at llnl.gov>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: RE: Utilizing StreamDevice in conjunction with sockets

 

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>
Sent: Monday, May 17, 2021 4:40 PM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: RE: Utilizing StreamDevice in conjunction with sockets

 

Hi Mark,

 

Thanks for the reply. Here are some clarifications.

 

1. The network interface speed of the instrument should be around 1 Gb/s.
2. The asyn command I used to create the port was drvAsynIPPortConfigure, which I had in the startup script named st.cmd. Priority, noAutoConnect, and noProcessEos are all set as 0.
3. The waveform record looks like this except I had to modify the record names.

 

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.

 

4. This is what the protocol for setCmd looks like.

 

setCmd

{

              out "%s";

              in ":%s";

}

 

5. I’ll try perf and asynTrace.

 

Thanks,

Andy

 

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Monday, May 17, 2021 2:24 PM
To: Wang, Andrew <wang126 at llnl.gov>
Cc: Pogge, James Robert <pogge1 at llnl.gov>; tech-talk at aps.anl.gov
Subject: Re: Utilizing StreamDevice in conjunction with sockets

 

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>
Sent: Monday, May 17, 2021 1:38 PM
To: EPICS tech-talk
Cc: Pogge, James Robert
Subject: Utilizing StreamDevice in conjunction with sockets

 

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