# Presentation: 683190

## Channel Access, CaSnooper, and CASW

- Kenneth Evans, Jr.
- Presented
- November 7, 2003
- Argonne National Laboratory

## Topics Covered

- Channel Access
- The means by which EPICS Clients and Servers talk to each other
- CaSnooper
- An application to monitor Search Requests for Process variables
- CASW
- An application to monitor Beacon Anomalies
- RunCaSnooper
- An application that provides an interface to CaSnooper and CASW with an associated MEDM and StripTool

## EPICS Overview

- Pump

- Power Supply

- Diagnostic

- Server

- IOC

- IOC

- IOC

## Concepts

- Network Protocols
- Process Variable Connection Process
- Search Request
- Exist Test
- Beacons
- Beacon Anomaly
- CaRepeater

## Network Protocols

- Channel Access uses two Network Protocols, UDP and TCP
- UDP (User Datagram Protocol)
- One way, unreliable
- Send out packets, no guarantee they reach their destination
- Can be broadcast or directed
- Broadcasts: To all IP addresses, e.g. 164.54.11.255
- Directed: To a specific IP address, e.g. 164.54.8.167
- Broadcasts do not leave subnets for security reasons
- TCP (Transmission Control Protocol)
- Two way, reliable, persistent
- Socket at each end
- Acknowledgements, timeouts, retransmissions, etc. guarantee reliability

## Connection Process

- Client, like MEDM, wanting a PV sends a UDP search request
- Sent to EPICS_CA_ADDR_LIST
- (Or its default -- broadcast to all interfaces on the host machine)
- Sent on EPICS_CA_SERVER_PORT [5064]
- Do you have this PV?
- Each Server that gets a packet does an exist test
- Do I have this PV?
- Server with the PV sends a directed UDP reply to the Client
- I have this PV.
- A TCP connection is established between the Server and the Client (or an existing one is used)
- One per Client-Server pair, no matter how many PVs
- Let’s talk.

## Search Request

- A Client makes a search request when it wants to find out what Server has the PV
- Happens when a PV is first created in the Client
- On a beacon anomaly  (still unresolved PVs only)
- When another PV is created (still unresolved PVs only)
- A search request consists of a sequence of UDP packets
- Starts with a small interval (30 ms), that doubles each time
- Until it gets larger than 5 s, then it stays at 5 s
- Stops after 100 packets or when it gets a response
- Never tries again until it sees a beacon anomaly or creates a new PV
- Total time is about 8 minutes to do all 100
- The sequence may be different owing to fine tuning
- Usually connects on the first packet or the first few

## Exist Test

- Every time a Server receives a search request packet, its pvExistTest routine is called
- The Server has to check if it has the PV
- Returns ExistsHere or DoesNotExistHere
- Normally a search request sequence ends after a few packets
- Because one Server soon returns ExistsHere
- For PVs that do not exist
- There are 100 tests per search request sequence for that PV
- This happens every time a Client initiates a search request sequence
- Each time the Client searches for a new PV
- At each beacon anomaly, perceived or real

## A Beacon is a UDP broadcast packet sent by a Server
When it is healthy, each Server broadcasts a UDP beacon at regular intervals (like a heartbeat)
EPICS_CA_BEACON_PERIOD, 15 s by default

When it is coming up, each Server broadcasts a startup sequence of UDP beacons
Starts with a small interval (25 ms, 75 ms for VxWorks)
Interval doubles each time
Until it gets larger than 15 s, then it stays at 15 s
Takes about 10 beacons and 40 s to get to steady state

Beacons go to CaRepeater, which forwards them to the Clients
On EPICS_CA_BEACON_PORT [5065]
Clients monitor the beacons for frequency changes (Beacon Anomalies)

- When it is healthy, each Server broadcasts a UDP beacon at regular intervals (like a heartbeat)
- EPICS_CA_BEACON_PERIOD, 15 s by default
- When it is coming up, each Server broadcasts a startup sequence of UDP beacons
- Starts with a small interval (25 ms, 75 ms for VxWorks)
- Interval doubles each time
- Until it gets larger than 15 s, then it stays at 15 s
- Takes about 10 beacons and 40 s to get to steady state
- Beacons go to CaRepeater, which forwards them to the Clients
- On EPICS_CA_BEACON_PORT [5065]
- Clients monitor the beacons for frequency changes (Beacon Anomalies)

- Beacons

## Beacon Anomaly

- A Beacon Anomaly is any change from the normal beacon interval (15 s)
- No beacons:
- After 30 sec the Client sends message over TCP connection
- If no beacons and no reply, connection is down
- That is when MEDM screens go white
- Abnormal interval:
- Short: IOC has come up
- Long: IOC was disconnected
- All cause Clients to reissue outstanding search requests
- Network problems can look like beacon anomalies

## CaRepeater

- UDP broadcasts are not guaranteed to go to every process on a workstation
- CaRepeater solves this problem
- There is one CaRepeater process per workstation
- Clients make a TCP connection to it when they start up
- CaRepeater receives the beacons
- EPICS_CA_REPEATER_PORT [usually 5065]
- CaRepeater forwards the beacons to the Client

## Summary

- Servers send beacons at regular intervals and with a faster pattern when they come up
- A Beacon anomaly is any pattern that is not a regular beacon
- Beacon anomalies cause Clients to send search requests
- Search request sequences end early for found PVs but not for non-existent PVs
- Search requests put a load on the Servers and add to network traffic
- This can cause problems
- Consequently, undesirable beacon anomalies and search requests should be minimized or eliminated

## CaSnooper

- CaSnooper is a Server whose ExistTest routine keeps track of Search Requests rather than seeing if it has the PV
- It can print the names of all PVs being searched for and related statistics using several report formats
- It can also check if these PVs are connected (C) or not (NC)
- It has internal PVs if started with the –n option
- Overall rates that can be monitored
- Others that allow it to be controlled from an MEDM screen
- The PV prefix [default CaSnoop] can be changed to prevent collisions
- Running CaSnooper:
- Run at the command line to get one report
- Run with PVs for monitoring, say with SDDSmonitor or StripTool
- Run with PVs and control with MEDM for continuous operation
- To run CaSnooper you need the full path
- /usr/local/epics/extensions/bin/solaris-sparc/caSnooper
- It is not installed for 3.13 (3.13 Servers have less capability)

## CaSnooper Options

## Sample CaSnooper Output

- Not connected, will be C for connected (hardly ever the case)

- Print top 10 (-p10)

- Check top 10 (-c10)

- machine:port, (can be used to identify source)

- name

- search rate in Hz

- statistics

- Two lines from RunCaSnooper

- individual name, prefix

## Control CaSnooper via MEDM

- Shell command to start CaSnooper, MEDM, StripTool, etc.

- Use these to set what will happen when you press Report.  Case illustrated will print the top 10.

- Cartesian plot of requestRate and individualRate

- Individual rate for CaSnoop.test, which doesn’t exist

- Request rate

- Execute selected reports in the CaSnooper stdout

- Reset the counters in CaSnooper

- Stop CaSnooper

- CaSnooper was started here (with EPICS_CA_REPEATER_PORT = default=5065)

## CASW

- CASW (Channel Access Server Watcher) monitors Beacon Anomalies
- Is a simple command-line utility
- Part of EPICS Base
- Need a full path to the version of base desired
- 3.14 (Recommended) /usr/local/epics/base3.14.3/bin/solaris-sparc/casw
- 3.13: /usr/local/epics/base/bin/solaris/casw
- Prints a line when it sees a beacon anomaly

- CaSnooper Starting

## StripTool

- Search for individual PV ended after about 8 minutes

- Reverse Gateways (1 min update)

- (Reverse Gateways, CaSnooper, and all IOCs see the same Search Requests)

- CaSnooper    (1 sec update)

- (CaSnooper was started here)

## OAG Monitoring

- The search request rates from the Reverse Gateways on the machine subnet are being continuously monitored
- You can can access the history from
- http://www.aps.anl.gov/asd/oag/logging/MonitorDataReview.html

## RunCaSnooper

- RunCaSnooper provides an interface to CaSnooper and CASW with an associated MEDM and StripTool
- Is part of IocappsTools (Type iocHelp for a list)
- By default it brings up an MEDM and  a StripTool and does not start CaSnooper
- If CaSnooper is running, the MEDM screen will not be white
- If it is white, you can start CaSnooper from the MEDM screen
- CaSnooper uses EPICS_CA_REPEATER_PORT=9876 by default, not 5065
- You can start also start CASW and StripTool from the MEDM screen
- Everything is generated on the fly and stored in /tmp
- Look in /tmp for:
- Logs of the CaSnooper reports and CASW output
- MEDM ADL file and StripTool configuration files
- Start it (type runCaSnooper) with no options:
- Displays extensive directions
- Then optionally allows you to start it (type y to continue)

## RunCaSnooper

## RunCaSnooper Options

## References

- Jeffery O. Hill, *EPICS R3.14 Channel Access Reference Manual*, (EPICS Documentation, 2003 or latest).
- http://www.aps.anl.gov/epics/modules/base/R3-14/index.php
- W. Richard Stevens, *UNIX Network Programming*, (Prentice-Hall, Upper Saddle River, NJ, 1998) Vol. 1.
- K. Evans, Jr., *CaSnooper Reference Manual, *(EPICS Documentation, 2003 or latest).
- _[http://www.](http://www.aps.anl.gov/epics/extensions/caSnooper/index.php)__[aps](http://www.aps.anl.gov/epics/extensions/caSnooper/index.php)__[.](http://www.aps.anl.gov/epics/extensions/caSnooper/index.php)__[anl](http://www.aps.anl.gov/epics/extensions/caSnooper/index.php)__[.](http://www.aps.anl.gov/epics/extensions/caSnooper/index.php)__[gov](http://www.aps.anl.gov/epics/extensions/caSnooper/index.php)__[/epics/extensions/caSnooper/index.php](http://www.aps.anl.gov/epics/extensions/caSnooper/index.php)_

## Thank You

- This has been an
- APS Controls Presentation

## Thank You

- This has been an
- APS Controls Presentation