[Hps] DAQ performance

[Arne Freyberger]

The number of beam trips is tracked and categorized in the downtime 
manager. 
(https://accweb.acc.jlab.org/dtm/reports/fsd-summary?start=02-May-2015+01%3A00&end=02-May-2015+15%3A35&maxDuration=5&max) 
Available on-site only.   Below is the number of trips per hour since 
1am this morning.  Nominally it looks like the rate is  about one RF 
trip/h  and the rest are associated with BLM/MPS, this is typically due 
to tuning or steering activity  in the hall lines. Hall-A stopped taking 
beam at 10am-1:30pm and the Hall-D line was steered up around 10:40,  
leading to a quiet period.   The purple Dump trips are "the cost of 
doing business"  due to the insertion of various dumps to aid 
tuning/steering.

The point is, every beam trip is not RF related, in fact at this energy 
there have been periods over 2h in length without an RF trip.

One more reason to look forward to single pass operation Monday and beyond.

Arne


On 05/02/2015 12:43 PM, Maurik Holtrop wrote:
> 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
>
> _______________________________________________
> Hps mailing list
> Hps at jlab.org
> https://mailman.jlab.org/mailman/listinfo/hps

-- 
Arne Freyberger
Director of Accelerator Operations
Jefferson Lab
12000 Jefferson Avenue      Cell: (757) 876-6289
Postal Suite 19             Email:  freyberg at jlab.org
Newport News, VA 23606

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/hps/attachments/20150502/0c5b2865/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gejddhde.png
Type: image/png
Size: 117602 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/hps/attachments/20150502/0c5b2865/attachment-0001.png