Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 16 Oct 2008 11:15:16 -0600

All,

> The entry for the gateway (172.23.106.35) is 'undefined'

That "<undefined>" string is supplied by the epicsTime::strftime() member
function when the time stamp fields, all of them, are zero (this corresponds
to a time stamp for the epics epoch which is safely interpreted to be a
nonsensical time stamp).

The hash table being dumped contains an entry for each beacon source seen by
the client library. The fields stored with each entry in that table are as
follows.
O address of the beacon's server 
O time stamp for when a beacon from this server was last received
O sequence number received in the last beacon message from this server
O a pointer to the data structure maintaining a TCP circuit to this server.
This is nill if no such circuit exists.

The timestamp field in that data structure can end up being undefined if we
have a TCP circuit to a server, but we have never seen a beacon from this
server.

Prior to R3.14.7 the client library would eventually (after a long timeout)
stop sending search messages altogether, and would not resume searching
unless it saw a beacon (period) anomaly. With R3.14.7 and later the client
library search rate exponentially decays to a plateau determined by the
EPICS_CA_MAX_SEARCH_PERIOD variable. 

The bottom line is that starting with R3.14.7 the client library doesn't
need to see a beacon anomaly to reconnect, but it will wait as much as some
N (N being almost always one) times EPICS_CA_MAX_SEARCH_PERIOD seconds prior
to reconnecting if it doesn't. 

Some additional details on the subtle CA client library behavior
improvements initiated in EPICS Base R3.14 can be found in the CA Reference
Manual.

Let me know if you have any additional questions, and best regards,

Jeff Hill

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Shepherd, EL (Emma)
> Sent: Thursday, October 16, 2008 9:39 AM
> To: [email protected]
> Subject: Inter-IOC link problems
> 
> Hi all,
> 
> We still seem to suffer quite a bit from problems with database links
> between IOCs, particularly when a gateway is involved.  For some reason
> the links can become disconnected and a reboot is usually necessary to
> get them working again.  I have just had an opportunity to do some
> diagnosis on one such problem and found a clue in the CA beacon
> hashtable part of the dbcar report.  The entry for the gateway
> (172.23.106.35) is 'undefined', although the gateway itself seems to be
> working just fine and I can use caget through the gateway as normal.
> 
> Any ideas what could cause this to happen, or how to fix it when it
> does?  None of the tasks are suspended, CPU usage is low and everything
> else looks fine.
> 
> CA beacon hash entry for 172.23.106.32:5064 with period estimate
> 15.000521
>         beacon number 168436, on THU OCT 16 2008 14:27:46
> CA beacon hash entry for 172.23.106.35:5064 <no period estimate>
>         beacon number 0, on <undefined>
> CA beacon hash entry for 172.23.106.97:5064 with period estimate
> 14.988265
>         beacon number 76356, on THU OCT 16 2008 14:27:52
> CA beacon hash entry for 172.23.106.96:5064 with period estimate
> 14.988637
>         beacon number 39491, on THU OCT 16 2008 14:27:53
> CA beacon hash entry for 172.23.106.98:5064 with period estimate
> 14.980477
>         beacon number 58989, on THU OCT 16 2008 14:27:47
> CA beacon hash entry for 172.23.106.102:5064 with period estimate
> 14.990867
>         beacon number 39993, on THU OCT 16 2008 14:27:53
> CA beacon hash entry for 172.23.106.32:5064 with period estimate
> 15.000521
>         beacon number 168436, on THU OCT 16 2008 14:27:46
> CA beacon hash entry for 172.23.106.35:5064 <no period estimate>
>         beacon number 0, on <undefined>
> CA beacon hash entry for 172.23.106.97:5064 with period estimate
> 14.988265
>         beacon number 76356, on THU OCT 16 2008 14:27:52
> CA beacon hash entry for 172.23.106.96:5064 with period estimate
> 14.988637
>         beacon number 39491, on THU OCT 16 2008 14:27:53
> CA beacon hash entry for 172.23.106.98:5064 with period estimate
> 14.980477
>         beacon number 58989, on THU OCT 16 2008 14:27:47
> CA beacon hash entry for 172.23.106.102:5064 with period estimate
> 14.990867
>         beacon number 39993, on THU OCT 16 2008 14:27:53
> entries per bucket: mean = 0.011719 std dev = 0.107617 max = 1
> 
> 
> Thanks in advance....
> 
> Emma
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> <DIV><FONT size="1" color="gray">This e-mail and any attachments may
> contain confidential, copyright and or privileged material, and are for
the
> use of the intended addressee only. If you are not the intended addressee
> or an authorised recipient of the addressee please notify us of receipt by
> returning the e-mail and do not use, copy, retain, distribute or disclose
> the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and
> not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> attachments are free from viruses and we cannot accept liability for any
> damage which you may sustain as a result of software viruses which may be
> transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England
> and Wales with its registered office at Diamond House, Harwell Science and
> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
> </FONT></DIV>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System