Summary: there seems to be a correlation between computer errors (for instance timing or IPC errors) with one or two types of blip glitches in DARM.

Explanation:

With the help of Dave Barker, in the last days I have been looking at several FEC_{}_STATE_WORD channels to find times of computer errors. First I used the minute trends to go back 90 days, and after that I used the second trends to find the times of the errors with an accuracy of a second (going back two weeks). I have been looking for error codes up to 128, where 2=TIM, 4=ADC, 8=DAC, 16=DAQ, 32=IPC, 64=AWG, and 128=DK. Finally, I generated omega scans of GDS-CALIB_STRAIN for the times of errors and found that they often show glitches.

Since there were some times that did not glitch, we are trying to track down how the coupling between the errors and the glitches is happening to see if it can be fixed or if the times can be vetoed. It might not be possible to fix the issue until we go into commissioning time at the end of O2, so DetChar might want to consider creating a flag for these times.

Investigations:

With the times obtained from the second trends, I have created tables of omega scans to see how the errors propagate and where the glitches appear. All those tables can be found here as html files, and the lists of times of errors for the last ~two weeks as txt files. So far, the model with the highest rate of glitches vs non-glitches is the susetm(x/y)pi.

I have been looking at some of these glitches, and the loudest ones coincide with small range drops. Also, the three glitches that had a strong residual in the subtraction of the MASTER signal from the NOISEMON signal (see aLog 34694) appear in the minute trends as times when there were computing errors (I haven't tracked those times down to the second though) in the h1iopsusey model.