Summary of the shift:

• at the beginning of the shift, we could not lock the SSFS, even by setting different gains and/or crossing frequencies of the two branches; after an adjustment of the attenuation of the IMC locking loop, this issue disappeared. Notice that both the Injection system and the "mechanical" frequency loop (CARM2MC) were working fine, it is the integration between the two via the SSFS that makes this tuning (very often) necessary, for some reason;
• after this issue, we could go reasonably fast through the lock acquisition without apparent issues; all the demodulation phases were good as yesterday, with the exception of the RFC (6MHz) and the SSFS (56MHz);
• at this point, we sistematically unlocked while trying to go to dark fringe, already during the hand-off for the MICH loop, with several symptoms (DARM oscillating at 100 Hz, MICH at 35 Hz, SSFS/INJ at 55 Hz) but no apparent cause; the obvious changing of loop gains did not cure the issue, nor it changed the frequency of such oscillations; Bas later pointed out that often the power transmitted from the IMC had some dip little before the unlock, but "recovering" in between the two events;
• looking at the Phase Camera signals, Annalisa pointed out that one of the 56 MHz sidebands had far less signal than the other one; the severe unbalancing could explain why handing-off MICH on a 56 MHz signal failed consistently;
• another issue at this point of the lock acquisition is the very high noise level of all longtudinal signals (see Fig.1) aside MICH (which is DC and not PDH), but mainly SSFS and PRCL, which are also relatives: the SSFS was much noisier in the intermediate frequency range, and with a huge peak exactly at 10kHz (plus several sidebands), which was not a gain peaking effect; PRCL had basically no sensing floor level (Fig. 2); again, the two quadratures of B4_56MHz were very coherent (Fig.3);
• at this point we tried to find a better working point for the ITF during the MICH offset reduction; indeed we found one by changing the working point of the PR alignment loop (which is a drift control that uses B2_QD2 as sensor): changing sign to the TY offset immediately made PRCL (and a bit SSFS) look better, at the cost of an apparently misaligned beam on the B4 camera and the occasional flashes when near dark fringe; the point is, after this change going to dark fringe consistently succeeded for the rest of the shift;
• once in dark fringe, as in the past days, the ITF condition is much more repeatable and the noise (although still present) is less of an issue, also thanks to the much better sensors we can use here for DARM and MICH; another effect we observed was that the 10 kHz structure immediately disappeared from the SSFS spectrum; notice that nothing happens on the SSFS itself during this transition;
• at the end of the shift some test on the PR full-bandwidth alignment loop was tried but with no success, we should explore the possibility that also its working point has changed w.r.t. yesterday.

I leave the ITF in LOCKED_SSFS, also to test if this "DAQ-burdening" state still impacts on olserver53 and the DAQ/Moni processes as it did last night. Now at the beginning, only the FdIOServer and MoniProcess are high on CPU usage.

EDIT: after 1.5 hours, the python process related to ITF_LOCK has reached 24% CPU usage and 1.4GB RAM usage, and increasing; my suspicion is that everything that the ezca library gets from the DAQ is stacked and not unloaded until the node changes state and deallocates everything.