You might have noticed the strange gap in the wind trend ndscope covering the time h1seib3 was down (plot 3). This is because when h1seib3's general cores went offline, the mx_stream process (which sends the front end data to the DAQ) stopped running. This in turn caused problems for all the front ends which share the same ethernet port on the DAQ data concentrator. This is why most of the corner station frontend models went into DAQ data error (plot 2), and why it was critical to fix the problem quickly. One of the models so affected was the external EPICS data collector h1edc running on h1susauxh34 (plot 1). So all slow data was also frozen at the last received value.
TJ mentioned in his alog that the LOCKLOSS_SHUTTER_CHECK.py guardian code had problems reading the HAM6 GS13 channel during the time h1seib3 was down. This was another symptom of the DAQ data being corrupted on most of the corner station models, in this case h1isiham6's data.
This guardian node reads the fast GS13 channel H1:ISI-HAM6_BLND_GS13Z_IN1_DQ from the NDS, which would have been a repeat of the last 62.5mS of data (16Hz). Looking at this channel's raw data would appear to show noise. The attached minute trend plot shows this data repetition over the period h1seib3 was down.
Just a note from the future: the new CDS DAQ scheme utilizing a non-Myricom driver for the data concentrator (in full-scale testing from before start of O3), does not suffer this particular pathology. This has even been proven on L1 CDS, where the new scheme is running parasitically to an alternate data concentrator in parallel with the old one.