DAQ Testing/20181102

Back to Main Page >> DAQ Documentation Portal >> DAQ Testing >> DAQ Commissioning Notes

Previous Day of Testing << >> Next Day of Testing

November 5th, 2018 Testers: Cameron

See Today's Meeting Notes

Goals

• Measuring ET bridge paradigm analyzer deadtime
  • Check that forced blocking deadtime actually affects DAQ readouts
  • Check that -nb, -n, -s, -q, and chunk size can or cannot help

Tests

• Run 4556 - non-blocking - simple analysis - 961.524 Hz set rate - 28.7829 % deadtime in analyzer - 0 % deadtime in DAQ
• Run 4558 - non-blocking - 200 us delay ana - 961.524 Hz set rate - 76.0947 % deadtime in analyzer - 0 % deadtime in DAQ
• Run 4561 - switching to blocking mode to see if the TI board cares about CODA
  • Run 4561 - blocking - 200 us delay ana - 961.524 Hz set rate - 0 % deadtime in analyzer - 0 % deadtime in DAQ
  • Run 4561 - blocking - 2,000 us delay ana - 961.524 Hz set rate - 51 % deadtime in analyzer - 0 % deadtime in DAQ
  • Run 4561 - blocking - 20,000 us delay ana - 961.524 Hz set rate - 82.1063 % deadtime in analyzer - 0.38 % deadtime in DAQ (after the run the ROC complains that "interrupt: Ev#172055: VQWK 0 timed out with timer=-200.logTask: 201 log messages lost." for a large number of events, probably the ones that were held up)
  • Run 4561 - blocking - 200,000 us delay ana - 961.524 Hz set rate - 98.5522 % deadtime in analyzer - 0.101346 % deadtime in DAQ
  • Run 4561 - blocking - 2,000,000 us delay ana - 961.524 Hz set rate - 99.949 % deadtime in analyzer - 0.0 % deadtime in DAQ
• Run 4562 - blocking - swapped the TI busy to ADC read signal and got no scaler incrementing for any time delays
• Run 4563 - blocking - restored it... maybe deadtime is differnent? (Ask Ed or Carl?)
• Run 4564 - blocking - when running at 2 seconds deadtime per event the TI busy out reads full rate 0 % deadtime, but if I go to a more reasonable number then the events catch up or something and the DAQ deadtime becomes non-zero
• Run 4565 - blocking - 20,000 us delay ana - 961.524 Hz set rate - 73 % and falling deadtime in analyzer - 0.6 % deadtime in DAQ and rising
  • I'm beginning to think that there is some very large buffer, and in order to see the backlogged data you have to run for a very long time... I think the DAQ is continuing to read out the data and store it for the ET to come and grab, but eventually it is getting fuller and slowing down... ROC 23 keeps reading events in spurts
  • Ending the run ROC 23 doesn't stop reading events, so I guess the data must be stored somewhere and has to be emptied before the run can end.
  • If I kill the etclient that is doing the time-delay analysis then ROC 23 ends immediately
• Run 4566 - non-blocking - back to normal - except interestingly the beginning of the run picket up a huge amount of left over events from the prior run... something is happening.

Results

I understand the ET system less now I think.

To Do

We should look at file sizes as a function of time. We should keep messing with the parameters. We should take the TS busy out and use that in the scalers too (needs a non-binary ECL cable and translation).