Subtle timing difference (~5 cycles) see on h1oaf1 during a lsc restart causing daqd crash
The question here is filtering out bad timing values. In the past we have seen restarts of lsc cause major (multi day) timing jumps for oaf1 that have caused the daqd to see a jump in data and restart.
Today we say a 5 cycle jump.
Aug 11 15:53:15 h1daqdc0 daqd[3306]: Dropped data from shmem or received 0 dcus; gps now = 1312757613, 0; was = 1312757612, 10; dcu count = 1 Aug 11 15:53:15 h1daqdc0 daqd[3306]: expected gps = 1312757612 Aug 11 15:53:15 h1daqdc0 daqd[3306]: expected cycle = 11 Aug 11 15:53:15 h1daqdc0 daqd[3306]: expected nano = 11 Aug 11 15:53:15 h1daqdc0 daqd[3306]: first 1 dcuids seen Aug 11 15:53:15 h1daqdc0 daqd[3306]: saw dcu 72 Aug 11 15:53:15 h1daqdc0 daqd[3306]: shmem_receiver looking for gps=1312757612 found 1312757611 on cycle 11 Aug 11 15:53:15 h1daqdc0 daqd[3306]: shmem_receiver looking for gps=1312757612 found 1312757611 on cycle 12 Aug 11 15:53:15 h1daqdc0 daqd[3306]: shmem_receiver looking for gps=1312757612 found 1312757611 on cycle 13 Aug 11 15:53:15 h1daqdc0 daqd[3306]: shmem_receiver looking for gps=1312757612 found 1312757611 on cycle 14 Aug 11 15:53:15 h1daqdc0 daqd[3306]: shmem_receiver looking for gps=1312757612 found 1312757611 on cycle 15 Aug 11 15:53:15 h1daqdc0 systemd[1]: rts-daqd.service: Main process exited, code=killed, status=11/SEGV