Re: spec Channel Access calls timeout

[Pete R Jemian <jemian@uiuc.edu>]

First off, use a subject line in your email messages.
Easier to track threads, better mileage, less filling, ...

Tim Mooney wrote:
>I haven't heard from users directly reporting long CA timeouts with spec,

I'll have to yell louder.  Much louder.
[Or purchase batteries and hearing aids for some folks.]
In all fairness, Gerry has always been the only person
I contacted to resolve this situation.

We've seen these spec timeout messages for
several years now.  Got Gerry to add a command,
for users to call at their discretion,
to set a different timeout for each EPICS PV,
in addition to the default timeout for all PVs.
Tried this with some really long timeouts.
This did not solve all our transient timeout issues.
But, for the most part, these timeouts were only
a nuisance and did not torpedo anybody's scans.

Tim Mooney wrote:
>though I have heard of problems thought to be CA related

Never once thought our issues were CA-related.
Other client tools (MEDM, et_wish, BURT) with
lots of PVs from the same IOC were running on
the same X display (and on other X displays as
well or in the background).  Those other clients
reported no such timeout issues.

As recently as this past weekend, users at two of our beam
lines noticed the familiar 'timeout' message from spec and
wondered what they should do.  (Answer was 'Ignore it.')

Never did learn how to diagnose this problem further because
it has not interfered catastrophically with our operations.

Tim Mooney wrote:
>My feeling is that we could spend an awful lot of time researching how to make
>things more robust, or spend a lot less time making sure we run in a regime in
>which CA is known already to behave robustly--i.e., unsaturated network,
>unsaturated processor, ample memory, and tested network hardware.  Either of
>these routes should get us to an acceptably low error rate.

Right.
We get these spec timeout messages with
100Mbps switched networks connecting
MVME2700 (ppc604) at 233 MHz with 64MB RAM
and Dell Dimension 600 MHz (or faster) RedHat Linux PCs.
I think we have modern, high-bandwidth hardware.
Still, not worth the time to investigate further
unless the timeout error rate goes up dramatically.

Mark Rivers wrote:
>Tom Trainor talked to Gerry today, and found that there is a way to trap
>errors in user macros, so that when an error occurs spec won't stop, but
>will instead go to the next command in the user command file.

What's the method?  Probably we all could benefit here.


Pete Jemian
UNICAT