asc filters

The h1asc filters which have been pending install since before ER9 were loaded.

framewriter testing

Jim, Dave

we continued testing of h1fw0 to investigate its instability. The daqd code was rebuilt against a later version of framecpp (2.4.2 instead of 1.19.32). When fw0 was instructed to write all frame types, it was as unstable with the older framecpp. The size of the science frames between the two writers at this point was different, with fw0's frame 2 bytes smaller than fw1's frame. We suspect the framecpp version string is encoded in the header, "2.4.2" is two chars shorter than "1.19.32". To get the frames the same size, we reverted fw0 back to framecpp 1.19.32.

The next test was to install a local 1TB 7200rpm SATA hard disk drive on h1fw0 and build an ext4 file system on it. The daqd process was directed to write to the local disk instead of the NFS mounted SATABOY. The disk access immediately sped up by many seconds. When we got the writer to write all four types of files, very surprisingly the frame writer still crashed, but took longer to do so. Writing all frames to the NFS-QFS crashed in less than 5 minutes, with local ext4 it crashing in 9 to 10 minutes. The crash time is not related to writing second trends, we saw several successful trend file writes over the several tests we ran. Monitoring the threads showed that with local disk the thread did not go into the "D" diskIO wait state. Another surprise was with local disk writing we did see a retransmission request about 40 seconds prior to the slew of requests at the time of crash.

We reconfigured fw0 backj to writing to ldas-h1-frames so they could be used to back-fill fw1's gaps.

As a test we had fw0 write commissioning frames only rather than science frames only. The data loading goes up from 0.9GB to 1.7GB per 64 second time period. fw0 is stable in this configuration. It can handle either 64 second frame, just not both.

We are leaving fw0 writing science frames overnight.