[Hps] DAQ performance

[Maurik Holtrop]

Hello Valerie,

Beam trip, or DAQ crash?

When the beam trips, which usually means an RF trip in the accelerator, I see no real reason to start a new run, although stopping and starting runs does not take a huge amount of time either, I don’t think it is necessary. So for beam trips, I don’t really see a problem that can be solved and we can probably just continue data taking when the beam comes back.

If there is a DAQ crash, you have no choice but to reset the DAQ. This does loose time, and I agree those issues need to be resolved. I see from the run sheet that there were about 3 DAQ crashes recently. Too many, but not too horrible. The Shifters should try to document the actual reason for the crash by preserving the diagnostic output in from the xterm window of the process that caused the crash. That will help Sergey diagnose the problem.

Best,
	Maurik
 



> On May 2, 2015, at 11:45 AM, Valery Kubarovsky <vpk at jlab.org> wrote:
> 
> Hi All:
> We started data taking with 50 nA beam current at 01:59 on May 02, 2015.
> It is a great achievement due to the hard work of the HPS team.
> Now it is time to improve the quality of the data and minimize the lost of beam time.
> 
> Looking at HPS run table I realized that up to now (11:28, 9.5 hours of data taking) we took 23 runs!
> ALL of them were ended with the beam trip! You can imagine how much beam time were lost due
> to the DAQ restarting.
> 
> Does anybody work on this problem? Can we avoid stop data taking after every beam trip?
> 
> Regards,
> Valery
> _______________________________________________
> Hps mailing list
> Hps at jlab.org
> https://mailman.jlab.org/mailman/listinfo/hps