We have been seeing a low rate of data drops with the frame writer serving as both the frame writer and the data concentrator for the DAQD 0 systems. This work is to try an alternate configuration. Moving the gds broadcaster to be a data concentrator and making the frame writer single purpose again.
The data drops are due to messages from teh front end arriving too late and being discarded. We are not seeing them on the DAQD 1 leg, only the 0. This leads us to tend towards the issue be the load (and thus responsivness to input messages) of the FW machine.
Today I adjusted the system such that GDS0 became the data concentrator and the broadcaster.
I've attached a diagram of the current layout.
The main changes:
- Link TW0 to GDS0, this was done first to ensure the data link worked well and TW0 keeps functioning.
- Add a 10G card into gds0 and two
- Moved TW0 to read data from gds0
- Move the FE input into the gds machine and reconfigure the FW machine to just be a receiver
The final migration followed this rough order
- stop cps_xmit, cps_recv, dix_xmit on fw0
- stop dix_recv on gds0
- move the fiber to gds0
- configure the interfaces on gds0 and start
- cps_recv
- cps_xmit
- dix_xmit
- configure fw0 to use dix_recv
The control room monitoring and medm screens still expect a DC, FW, TW, NDS, and GDS. So gds0 as the DC is exporting DAQ-DC0 variables, and we are running a epics proxy ioc which maps DAQ-GDS0 channels to DAQ-DC0 for now. This will change in the future. Most of the DC0 variables will probably be taken over by the cps_recv process (this is in testing on the large test stand in LLO).
There were a few daqd restarts to make sure everything was working. Data is flowing and fw0 and fw1 are producing identical frames.
The plan is to let this run though til January and evaluate the error rate.
