Reports until 11:48, Friday 20 April 2018
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 11:48, Friday 20 April 2018 - last comment - 14:23, Friday 20 April 2018(41562)
RGC 3.4 testing status

h1susauxb123 and h1pemmx front end systems are both running RCG3.4.2/Gentoo3.0.8 with no current issues.

The problem of the models not starting automatically on reboot has been resolved.

There have been some occasional  DAQ issues seen when h1susauxb123 models were started/stopped. Specifically: sometimes when the models are stopped the DAQ data from h1seih16 were glitched (running start_streamers.sh on susaux123 clears this). During some starts of the code the DAQ status for the models h1susopo and h1ascimc were flashing between 0x0 and 0x2000. This was when the susaux models were not starting correctly, has not been seen since.

One surprise, after recompiling h1susauxb123 the resulting DAQ-INI file was different. The file h1susauxb123.mdl has not been modified since 2015, so I suspect some of the common mdl files used by this model have been modified recently.

Comments related to this report
david.barker@LIGO.ORG - 12:12, Friday 20 April 2018 (41564)
Link

due to INI file mismatch, DAQ data from h1susauxb123 is currently not correct. I'll revert it back to RCG3.2 soon.

david.barker@LIGO.ORG - 13:00, Friday 20 April 2018 (41565)
Link

h1susauxb123 is now back at RCG3.2 with good DAQ data. Due to the recent model changes, I did not perform a new rebuild against 3.2 as this would require a DAQ restart. Instead I restored the target directory, the DAQ-INI and the GDS-PAR files from archive. I restored the 3.2 version of awgtpman as well.

While h1susauxb123 was being reverted, DAQ data from h1seih16 was again invalid for a few minutes.

keith.thorne@LIGO.ORG - 14:23, Friday 20 April 2018 (41566)
Link 

The interruptions in the mx_stream when testing h1susauxb123 may be due to differences in the indexing of the mx_stream slots (i.e. which of the two 10G cards, which of 16 slots on a card) between the old boot server (h1boot0) and new boot server (h1boot1).   The relevant files are '/diskless/root/etc/init.d/mx_stream' on both boot servers.  On the test stands, there were tests to avoid use of slot 0, because it seemed to be affected when mx_streams in others slots were redone.