Kevin,
If your CA client has process variables that are not present
in any server then it might be searching to find them. By
default CA uses IP broadcasting when it is searching. To
allow good performance when connecting large numbers of process
variables the clients will temporarily broadcast at a rate similar
to what you are observing. When clients are not receiving replies
for most of the process variables that they broadcast for, and
there are no new severs on the LAN, then they exponentially increase
the period between broadcasts. Eventually, they stop broadcasting
and only resume broadcasting again when they detect a new server
(they see a CA server beacon anomaly).
I recommend the following:
1) If this machine is an IOC, then run "dbcar" to see if any
database links are disconnected. With increasing level you can see
the names of the CA links, and determine if any of the process
variable names are wrong. See the application developer's guide for
the details. If there are sequence programs in this IOC then I would
run similar diagnostics on the sequencer. Otherwise, you will need to
run client specific diagnostics to see if there are process variable
names that are configured, but not present in your system.
2) There is a program "casw" in EPICS R3.14 that will identify
servers that have abnormal beacons. Typically CA only detects a
beacon anomaly when a server restarts (an IOC reboots) or when
there are problems with network connectivity. However, with
strange routing configuration and possibly also unusual use
of EPICS_CA_ADDR_LIST you can configure a system where CA
clients continuously detect beacon anomalies. This can cause all CA
clients to not exponentially back off their search request period.
3) You are using EPICS R3.13.0Beta12. I seem to recall that some
improvements were made in the code implementing exponential back off
for the period of CA search messages after EPICS R3.13.0Beta12. It
might help to upgrade to EPICS R3.13.4.
Finally, for my benefit, please run "spy" in your IOCs to see if
the CA server's UDP task is using any CPU resulting from your broadcasting
rate.
Feel free to E-mail with any additional questions that you might have.
Jeff
>
> We're still using EPICS R3.13.0Beta12 and frc40s.
> In a recently installed application, I've discovered
> that its broadcasting the following message at a very
> high rate (~80-90 msgs/sec):
>
> laser3 -> 128.171.96.255 UDP D=5064 S=1026 LEN=56
>
> Looking through the documentation I found that UDP port 5064
> is used for process variable name resolution.
>
> Can anyone tell me how what exactly is it trying to do and
> how to fix it or at least reduce the broadcast rate.
>
- References:
- dbCaLink and broadcast messages Kevin Tsubota
- Navigate by Date:
- Prev:
Re: devVXStats and task crash Marty Kraimer
- Next:
EPICS training Nick Rees
- 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
- Navigate by Thread:
- Prev:
dbCaLink and broadcast messages Kevin Tsubota
- Next:
Re: dbCaLink and broadcast messages Kevin Tsubota
- 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
|