Re: spec Channel Access calls timeout

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

Whew!  Busy thread.

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

Great question.  Don't know how to find the answer.
Doesn't spec have a debug mode wherein we can examine
the communications sent/received by spec?
Anyone remember how to do that?  I believe the output
can be logged to an external file so that the diagnostics
don't have to appear on the user's console.

Tim wrote:
>If long timeouts don't make the problem go way, then my first
>guess would be that messages are being discarded.  It would be
>nice to know whether this is happening on the server side or on
>the client side.  If server side, I think CA should be writing error
>messages to the console, and you wrote some software to store
>console output to files, right?  If there's no telltale in your
>files, then maybe the messages are being discarded on the client
>side.


We've got users in this week who will be using spec on one
of our beam lines.  I'll see if I can dredge up that
communications logging command (if someone doesn't post that here
before I find it) and see if I can synchronize any spec timeout
messages with my VxWorks console logs.

Mark wrote:
>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.

Mostly, this is our experience.


One more piece of anecdotal information that anyone can
try for themselves.  One time, I was setting up a naive
tool to archive a lot of beam line information.
Using BURT, I set up a request for thousands of PVs
from a single IOC and caused it to crash (probably a
mv162 with 8MB RAM).  I suspect the crash was because it ran
out of memory while allocating space to respond to
the BURT request.  IF we suspect that it is the IOC which
is triggering the spec timeout messages, then we could force
the issue using this method.

Pete