There is some possibility to occur a same error in FIND_IR_RESONANCE because they use a same method to take data.
When it's occurred in FIND_IR_RESONANCE guardian, it may interrupt auto recovery of IFO lock.
So I started to work for mitigating this issue.
I haven't identified yet whether CPU load or disk speed is a cause of this issue.
In order to identify the cause, I prepared tertiary NDS as k1nds3 at U13-14 of C2 rack.
If it comes from CPU load, situation should be improved by distributing loads to 3 NDS servers.
k1nds3 is already working as NDS server.
But CPU load hasn't been distributed yet because health check measurements are now running.
After finishing health check, I will do remaining work.
-----
Memo:
- constructed a boot disk from a backup of k1nds1
- changed hostname on /etc/conf.d/hostname and /etc/hosts
- changed IP addr on /etc/conf.d/net and /etc/conf.d/local.start
- built and installed ixgbe to use Intel-10GigE NIC (k1nds0,1 use Myrinet NIC)
- set load option for ixgbe on /etc/conf.d/local.start
/sbin/rmmod ixgbe- copied /opt/rtcds/kamioka/k1/target/k1daqnds1 to /opt/rtcds/kamioka/k1/target/k1daqnds3
/sbin/insmod /lib/modules/3.0.8/updates/drivers/net/ethernet/intel/ixgbe/ixgbe.ko allow_unsupported_sfp=1,1,1,1
- edited daqdrc by sed -e 's/nds1/nds3/g'
- edited /etc/inittab by sed -e 's/nds1/nds3/g'