RE: spec Channel Access calls timeout

[Mark Rivers <rivers@cars.uchicago.edu>]

Pete,

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

Right, I realized that, of course, right after I sent the message ...

> 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.

Do you know what PVs those timeouts are occuring for, and are they Puts or
Gets?

> 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.

medm does not do ca_get, right, it just uses callbacks.  Some other clients
(IDL, Visual Basic) use the ezca library, which implements retries.  I don't
know about BURT and et_wish.  But I agree, I don't see timeouts in other
clients with one exception: if one does a ca_put_callback(), which waits for
records to fire their forward link, and does this to a record which can take
a long time to fire it's forward link (motor, scaler, mca, etc.), then
you'll see a timeout.  But this is a programming error.

The only times we have gotten the timeouts in spec are when we believe we
had a flaky network hub.  Replacing the hub and a couple of nights of
beating hard on spec and CA we could not reproduce the problem.

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

I'll find out from Tom and get back with the answer tomorrow.

Mark