I stopped daqd several times during 18:50-21:40 for investigation of DAQ instability.
Memo for DGS folks
There was no improvement
- by restarting the MX process on k1dc0,
- by re-arranging the end point assignment.
Even if the end point assignment was changed, the condition that DAQ became stable was not changed.
Only when mx_stream on PR2, PR3, PRM or IOO1 was stopped, DAQ process worked stable.
Tested end point assignment is as follows.
| 0 | SRM(1059) | SR3(944) | |
|---|---|---|---|
| 1 | LSC0(5862) | ||
| 2 | ASC0(4193) | ||
| 3 | IOO(2640) | ||
| 4 | IOO1(1741) | ||
| 5 | ALS0(1563) | ||
| 6 | IX1(1506) | ||
| 7 | IY1(1486) | ||
| 8 | EX1(1553) | OMC1(11) | |
| 9 | EY1(1552) | MCF0(365) | |
| 10 | TEST0(1436) | PRM(754) | |
| 11 | EX0(1526) | PR0(701) | |
| 12 | EY0(1282) | PR2(708) | |
| 13 | OMC0(1212) | PX1(948) | |
| 14 | IMC0(1123) | BS(926) | |
| 15 | IY0(1007) | SR2(925) |
In this assignment, amount of data on each end point is uniformity as much as possible.
So this result suggests that instability problem of DAQ isn't caused by ununiformity of load on a part of end points.
On the other hand, a number of combinations of two models which become 0xbad at the same time is decreased in this assignment.
We may need to consider the amount of data on each real-time front-end.
After today's investigation, I reverted the end point assignment for another tests which will be done tomorrow or later.