Re: Channel Access Timeouts - ca(get|put) CA Priority

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Gary,

On Jul 26, 2021, at 11:27 AM, Yendell, Gary (DLSLtd,RAL,LSCI) <gary.yendell at diamond.ac.uk> wrote:

I will look into that. I also tried running caSnooper:

$ caSnooper -t60 -p10 -c5

Jul 26 15:26:18:

There were 15078 requests to check for PV existence for 1960 different PVs.

  Max(Hz):   5.58

  Mean(Hz):  0.13

  StDev(Hz): 0.36

So all your IOCs on that subnet were being asked to check 15078/60 = 250 PV names per second in addition to the other work that they have to do. I could see that having some effect on them, although it will affect different OSs and IOCs differently.

I have found many instances of a db expansion where the macros are not substituted correctly, so there are multiple records requesting the PV " CP" (and maybe "CP" - although I can't find those, so maybe it is just the output formatting)

e.g.

record(longout, "BL07I-EA-DET-10:OVER:1:PositionXLink")

{

    field(DOL,  " CP MS")

    field(OMSL, "closed_loop")

    field(OUT, "BL07I-EA-DET-10:OVER:1:PositionX PP")

    info(autosaveFields, "DOL")

}

The above DOL field would be parsed as a CA link to a PV named “CP” with the link flag “MS” since leading spaces are stripped while parsing the name. I’m not sure where your “ CP” PV searches might be coming from, probably from some other CA client which doesn’t do that.

Is it possible these requests are putting significant extra load on the IOCs?

It is possible, the best way to find out may to clean up the subnet if you can. If you can’t reboot the IOCs that are making the requests you could use caput to change the link field to a number or an empty string which will stop them running CA searches at least until they do next reboot (they will never connect to the current names, so you won’t be doing any harm to those IOCs anyway).

HTH,

- Andrew

-- 

Complexity comes for free, simplicity you have to work for.