Page History

...

(diagnostic) UNSOLVED: according to hsdpva only one hsd was producing dead time (due to msgdelay being set too short) but xpmpva showed all hsd's having dead time.  at other times xpmpva seems to be attributing dead time correctly, so it's somehow an intermittent issue, perhaps only happening when Ben detects his front-end buffers have overflowed?  (which causes him to latch dead time until receiving clear readout).

(diagnostic) UNSOLVED: Started a run with 5 hsd pairs.  Got to state Running with GroupCa's NumL0Acc going to 23 before the system went into 100% dead time.  GroupCA attributed it to HSD:dev07.89.  xpmpva for XPM:1 shows no deadtime for any device in my group (3), while for XPM:2 the link to XPM:1 shows ~1.0.  Perhaps the XPM:1 DeadTime tab is not updating at all since all Group columns show 0.0000.  Found '172.21.148.110:34458 : Connection closed with RX socket error 113' in the pyxpm-1 log file.  Restarted the process.  No change.  Restarted xpmpva.  No change.  However, now HSD:dev07.1a is shown to be the source of the deadtime in both groupca and the xpmpva deadtime tab for XPM:2.

(diagnostic) UNSOLVED: got a segv in this log file: /reg/neh/home/cpo/2020/06/15_18:39:03_daq-tst-dev03.pcdsn:hsdpva.log (and again in /reg/neh/home/claus/2020/07/24_17:12:50_daq-tst-dev02:hsdpva.log, twice).  restarting the process fixed it.  Later, saw this log /reg/neh/home/cpo/2020/06/16_15:49:13_daq-tst-dev03.pcdsn:hsdpva.log:

...