> Grasping at straws, I started killing MEDM displays on the control workstations. One of them
> was an XY plot of beam profiles (~75 channels total @ 30Hz rate). Turning that
> display on and off had almost the same effect on the stalling problem (turned
> on, big problem; turned off, almost no problem).
I still have no explanation, but have found what appears to be a fix (or at least a
work-around).
Let's review for clarity: iocA gathers lots of data which iocB gets via CA in a subroutine
record to display on DROs. That same data can be displayed on an OPI via MEDM, but hangs as
often as iocB's DROs. To further complicate the problem, there is an even more remote iocC
which gathers beam profile data and sends waveforms back to the OPI for an XY plot display. All
the iocs were on thinnet (10base-2, if you prefer) and were connected via an adapter box to a
10/100base-T hub. The OPIs and are connected to the hub. Oh and iocA, C, and two others are on
the other side of a fiber-optic network bridge.
This morning, I pulled iocB off the thinnet and gave it a port on the 10base-T hub. The problem
all but vanished. I tried other combinations (putting iocB back on thinnet with a different
connector box, and separating leg with iocA, C, and two others (the fiber bridge) and putting
it into the hub directly) trying to understand what was happening, but iocB being on the hub by
itself seemed to be the only thing that really mattered.
The way it was, data from iocA to iocB appeared to get delayed by data from iocC to the OPI.
That kind of made sense since data from C to the hub and OPI had to physically pass iocA and B
on the network. Just moving iocB to the hub means that now the data from A to B has to take
exactly the same route except for going one step further by going into and out of the hub. A
and C still share the fiber bridge, cable from the bridge to the adapter, adapter, and hub
port. Why doe that work better? My thought was that the problem was actually with the
transceiver on iocB, but a different one did the same thing. Cable? All the data still goes
through it, the "T" just isn't connected to anything any more? Bad "T"? Possible, but not
likely since the other legs of it are fine and, keep in mind, the sniffer never did see any
problems with the network. Bad cables tend to show up pretty readily.
So, any ideas? Anybody?
Thanks everybody for your help.
Garrett Rinehart
Intense Pulsed Neutron Source
Argonne National Laboratory
9700 S. Cass Ave
Argonne, IL 60439
(630)252-6561
PS: John, I see your point about Peregrine's heartbeat, but I'm seeing the same problem with
floating point numbers that change constantly.
- Replies:
- RE: CA monitors...Update #2 Jeff Hill
- Navigate by Date:
- Prev:
Re: Delays in receipt of CA monitors john sinclair
- Next:
Re: Delays in receipt of CA monitors Peregrine M. McGehee
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: HP VXI Monitoring Dave Gurd
- Next:
RE: CA monitors...Update #2 Jeff Hill
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|