Re: asyn timeout

["Paduan Donadio, Marcio" <marcio@slac.stanford.edu>]

Hello, Mark.

Giving the amount of sub-systems and different ages of equipment/software, we can have systems that are running stable and untouched for many years, systems that​ were upgraded recently, or few years ago, and systems that are being setup right now with the most recent module versions.​ I should have said that we are using Asyn-4-18 in production for this specific equipment. Now, rereading my text, the way I said seems that all our systems in production are using 4-18, which is not the case.

So, it seems that upgrading our IOC for this equipment now is a wise thing to do. I will test to check how many dependencies need to be upgraded and finally discover if your suggestion works well in our case.

Thank you for all the answers,

Márcio Paduan Donadio

Software Engineer - SLAC - TID/AIR/ACS​

---

De: Mark Rivers <rivers@cars.uchicago.edu>
Enviado: sexta-feira, 2 de junho de 2017 16:31
Para: Paduan Donadio, Marcio; Tech-talk@aps.anl.gov
Assunto: RE: asyn timeout

 

Hi Márcio,

 

> We are using Asyn 4-18 (November, 2011) in production. Do you think it would work for me to cherry pick the commit where you implemented this asynOption key and include it in my 4-18?

 

Which SLAC systems are still running 4-18?  That is a very old release, and there have been a number of fixes since then, some of which were particularly targeted at SLAC/LCLS.

 

These are the major fixes from the release notes that affect drvAsynIPPort and timestamps (which were done for SLAC/LCLS).

 

I am rather doubtful that a cherry-pick is going to work since there have been so many changes since R4-18.

 

R4-27

drvAsynIPPort

Added the option to automatically close the port when there is a read timeout. This was done by changing the syntax of the drvAsynIPConfigure command from
drvAsynIPPortConfigure("portName","hostInfo",priority,noAutoConnect,noProcessEos) to 
drvAsynIPPortConfigure("portName","hostInfo",priority,noAutoConnect,userFlags)
userFlags: bit-wise ORed:

• Bit 0 is USERFLAG_NO_PROCESS_EOS. If 0 then asynInterposeEosConfig is called specifying both processEosIn and processEosOut.
• Bit 1 is USERFLAG_CLOSE_ON_READ_TIMEOUT. If 1 then the (TCP) socket will be closed when read() returns a timeout.
• Bit 2--31 are reserved, set to zero.

This change is backwards compatible since bit 0 is the same as the previous noProcessEos. Thanks to Torsten Bogershausen for this change.

 

R4-22

drvAsynIPPort

Fixed a bug in calling poll(). Previously the status return from poll() was not being checked; it was assumed that when poll() returned the port either had new data or had timed out. This is not correct, because poll() can return prematurely with errno=EINTR if a Posix signal occurs before data is received or the timeout expires. This can happen, for example, when the Posix high-resolution timer routines (timer_create, etc.) are used in the IOC. The Prosilica vendor library uses the Posix timer routines, and there were problems using asyn IP ports in IOCs that were also running Prosilica cameras. The problem was fixed by calling poll() again if it returns EINTR and the desired timeout time has not expired since poll() was first called.

Added support for AF_UNIX sockets on systems that provide them.

asynDriver

Added support functions for setting timestamps in asyn port drivers. These can be used to set the timestamp when the port driver received data. The driver can then set the asynUser->timeStamp field to this value for all input records on read and callback operations. Records that have TSE=-2 will have this timestamp. There is support for registering a user-supplied function to provide the timestamp, which will override the default source that just calls epicsTimeGetCurrent().

 

R4-21

asynDriver

Restored the original versions of pasynManager->lockPort and unlockPort that were used in asyn prior to R4-14. These versions just call epicsMutexLock and epicsMutexUnlock. In R4-14 these versions were replaced with versions that queued requests to lock the port. The R4-14 versions fixed a problem with the interfaces/asynXXXSyncIO functions, but it has become clear that the original versions are useful in some circumstances. The change was done as follows:

• The lockPort and unlockPort functions in R4-20 were renamed to pasynManager->queueLockPort and queueUnlockPort.
• The interfaces/asynXXXSyncIO functions were all changed to call the queueLockPort and queueUnlockPort, so they function identically to how they have since R4-14.
• The versions of lockPort and unlockPort that existed prior to R4-14 were restored to pasynManager.

Changed the report() function so that if details<0 then asynManager does not print information for each device (address). It calls pasynCommon->report(-details) in this case so driver report functions will not be affected.

Changed the asynTrace print, printIO, vprint, vprintIO functions so they use EPICS_PRINTF_STYLE. This causes the GCC (version 3.0 and higher) and clang compilers to check the agreement of format strings with function arguments when using asynPrint() and asynPrintIO(), just as they do with printf(). This is very helpful in finding errors, and uncovered a number in asyn itself, which have been fixed.

 

Mark

 

 

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Paduan Donadio, Marcio
Sent: Friday, June 02, 2017 5:54 PM
To: Tech-talk@aps.anl.gov
Subject: Re: asyn timeout

 

Hello, Mark.

 

Probably it will work very well in our case. I will try this here and return to you as soon as I have a result. Thank you for this!

 

We are using Asyn 4-18 (November, 2011) in production. Do you think it would work for me to cherry pick the commit where you implemented this asynOption key and include it in my 4-18?

 

Thank you again,

 

Márcio Paduan Donadio

Software Engineer - SLAC - TID/AIR/ACS​

 

 

---

De: Mark Rivers <rivers@cars.uchicago.edu>
Enviado: sexta-feira, 2 de junho de 2017 13:25
Para: Paduan Donadio, Marcio; Tech-talk@aps.anl.gov
Assunto: RE: asyn timeout

 

Hi Márcio,

 

Have you looked at the asyn R4-29 release notes?  It says this:

 

****************************

drvAsynIPPort now also directly supports the asynOption interface for 2 key/value pairs.

  - key="disconnectOnReadTimeout", value="Y" or "N". This option replaces the USERFLAG_CLOSE_ON_READ_TIMEOUT that was introduced in R4-27.

   The advantage of using the asynOption interface is that this behavior can now be changed at run-time, rather than being set once when the driver is created.

****************************

 

Since your device sends data every second, you can set the "disconnectOnReadTimeout" option and then read the device with a 10 second timeout.  If it times out then it will reset the connection.  Would this work for you?

 

Mark

 

 

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Paduan Donadio, Marcio
Sent: Friday, June 02, 2017 2:55 PM
To: Tech-talk@aps.anl.gov
Subject: Re: asyn timeout

 

 

Hello, everybody.

 

I am sorry to resurrect such an old thread. Mark, did you implement the optional keepalive support to the asyn socket driver, yet?

 

Here in SLAC we are seeing a scenario where it would be really useful. We have an equipment that sends data each second through a serial to ethernet converter. This equipment does not accept any commands. Eventually, the converter reboots and Asyn receive no warning. So, for Asyn, we have an alive connection with no data, and for the converter, there is no active connection.

 

I tried this using only telnet without an IOC running and the behavior is the same: telnet does not know that the connection was broken with the converter.

 

The keepalive parameter would help us a lot in this case.

 

By now, we are implementing the workaround you suggested in tech-talk "Force TCP/IP reconnect from Asyn/Streamdevice" thread (http://www.aps.anl.gov/epics/tech-talk/2017/msg00863.php).

 

Thank you!

 

Márcio Paduan Donadio

Software Engineer - SLAC - TID/AIR/ACS

 

----------------------------------------------

Subject: Re: asyn timeout

From: Pedro Gigoux <pgigoux@gemini.edu>

To: Mark Rivers <rivers@cars.uchicago.edu>

Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>

Date: Mon, 19 Oct 2015 18:24:12 -0300

Hola Mark,

 

I'd be happy to test the keepalive option when it's ready. It may not happen immediately since the instrument is a shared resource and the time to use it is allocated in blocks.

 

Thank you,

Pedro.

 

On 19 October 2015 at 16:10, Mark Rivers <rivers@cars.uchicago.edu> wrote:

Hi Pedro,

 

 

 

It seems like it might be a good idea to add optional keepalive support to the asyn socket driver.  If I were to create a branch on github that implemented this would you be able to test it?

 

 

 

Mark